git-config and Windows

[edward-shen]

Unlike MacOS and Linux-based distros, git on Windows has been (; sitll is?) relatively fractured. For example, you have three installation locations based on which native environment (read: not WSL or WSL2) you have:

• For msysGit: %ProgramFiles(x86)%\Git\etc\gitconfig
• For Git for Windows (64 bit): %ProgramFiles%\Git\mingw64\etc\
• For MSYS2-native git: [MSYS2-install-path]\etc\gitconfig

git works around this by having a compile-time variable $(prefix) that presumably is configured when building git for these environments.

Unlike git, git-config in isolation is used as a library, which means that we can't simply just assume which environment we're working in, especially for MSYS2-native, which does not have a compile-time known installation path.

There are various paths moving forward that I've considered (subject to change; suggestions appreciated):

1. Drop Windows support entirely, since it's reasonable to assume that significant development on Windows is done through WSL at this point.
2. Support Windows, with feature flags for msysGit and Git for Windows, dropping support for MSYS2-native.
3. Support Windows, with feature flags for all three common Windows environments, and require MSYS2-native to provide an installation path during construction.
4. Support Windows, and require Windows builds to always point to a path for system-wide configuration.

If we chose to support Windows native git environments, we also need to consider how to test for this: I don't have a Windows environment, so testing for even one of the native implementations is difficult for me. We might need to spin up additional workflows for git-config if we want proper testing on Windows.

I'm conflicted as all the paths moving forward with git-config on Windows has their own strong, valid merits. so feedback would be greatly appreciated.

[Byron]

Thanks for the elaborate summary, I think I understand what the problem is.

Since git-config has all right to consider itself plumbing, it doesn't have to be smart about these paths. Hence I wouldn't expect it to read GIT_* environment variables for auto-configuration, at least not by default.

Thinking further in that direction, what about supporting such a prefix as part of the configuration? Then the problem can be shifted a level higher so that git-repository can deal with solving it.

Edit: Technically git-config only has to support this case as configured by the crate's user, but doesn't have to know the 'unknowable'. Ultimately the crate is not tied to git at all either, so it might even have its own configuration path there, i.e. gitoxide's gix program sets something up that matches its preferred installation directory in Windows, and other tools using it may use their own or make the prefix configurable by the user even.

What do you think?

[edward-shen]

Thanks for the feedback. I suppose requiring users to set the prefix and then provide const for macos and linux would be a good way, so it's not too difficult for the end user.

[Byron]

This sounds good to me. Part of me wonders if linux paths can actually be guessed, thinking of nix distros specifically. Maybe there is a crate for that though.