Improve hooks tests

[EliahKagan]

This improves the tests of git hooks in test_index.py:

• f664a0b fixes and adds missing xfail marks for the WinBashStatus.Absent condition. This is a test bug from when I added the xfail marks in #1745. The Absent condition was detected correctly, but not always used, or used properly, in xfail markings.
• e148647 adds a direct test of run_commit_hook itself. The other tests test specific kinds of hooks. run_commit_hook is public so it's reasonable for it to have its own test, plus I anticipate this will help future work.

Their commit messages include some more details, including rationale.

I have made sure to test on a Windows system that truly does not have bash.exe (as well testing the WinBashStatus.Wsl case, which CI confirms, and the WinBashStatus.Native case).

One might worry that I missed this before due to some further bug, but I believe not. Producing a genuine WslBashStatus.Absent condition on a Windows system that has a system-provided WSL-related bash.exe in System32 (which is searched regardless of what is in the PATH environment variable, as noted in the WinBashStatus.check docstring) is a bit tricky because renaming that file requires one to act as the TrustedInstaller user (as would the worse option of deleting it). At some point while working on #1745, I did not test this when I should have. I believe that is the only reason it was missed, rather than any underlying technical issue.

[Byron]

Thanks a lot for the continuous improvement!

Windows support in conjunction with hooks is rather complex, but I hope I can learn from it to one day have equal or better hooks support in gitoxide, even when compared to Git itself.

[EliahKagan]

I think the main challenge for hooks in GitPython is backward compatibility. So if, for hooks, that concern is lesser, or absent, in gitoxide, then I would expect its support for hooks could be better soooner.

In GitPython currently, hooks in Windows run with whatever bash.exe is available, which in practice is often the WSL-related bash.exe in the System32 directory, even often when there are no WSL systems installed, such that any and all attempts to run a command with that bash.exe are guaranteed to fail. In addition, running hooks in the WSL system in connection with git operations outside of it is something I suspect will never be able to work quite right in a significant fraction of uses. Yet I am also reluctant to break uses that may be effectively depending on it.

Most installations of git on Windows are via the Git for Windows project. Most of those are "full" installations, where a bash shell and various standard Unix utilities are available (though the project does also provide something called MinGit which is more limited, and not to be confused with git from MinGW or MinGW-w64, which are fully featured). One has a full installation when one uses the downloadable installer, but also when one installs in other popular ways, such as with the Scoop or Chocolatey package managers. "Full" is not a recognized term; I just don't know the word or phrase for this.

Assuming the existence of a Bash shell associated with a Git for Windows installation, the natural way to run hooks (if their hashbangs indicate they are shell scripts) is to use that. After all, that bash.exe is what git on such a system is using to run git commands that are shell scripts, including custom commands.

More broadly, I think it should be feasible to run any script with a hashbang in the manner git runs it on Windows using its accompanying MSYS2-like environment (of which its bash.exe is a part).

[Byron]

Thanks for elaborating on this!

I realise now that I always look at the canonical Git repository, not at the one that contains the various patches to build the "Git for Windows". This means that on Windows, gitoxide could have special handling to determine the kind of installation, and find the right shell to use. Right now it relies on sh.exe being in PATH effectively, whenever a shell has to be used. The logic for that is exclusively in gix-command, which is pretty straightforward still.