Approaches to solve for different Git Credential Manager versions on the PATH

[dscho]

Currently, Git for Windows ships with Git Credential Manager included. That means that git config credential.helper manager-core (hopefully soon manager instead of manager-core) will always use the bundled version.

That is typically not a big deal because Git for Windows' release cadence seems to be frequent enough.

However, occasionally users need to download and install a newer Git Credential Manager version, and that installation will then have to use the absolute path to its executable to prevent Git for Windows from preferring its bundled version.

It would be good to find a solution to this problem.

One potential approach would be to move Git Credential Manager from libexec/git-core/ to bin (which should be done anyway because Git Credential Manager is not part of the core Git project per se) and then ship with a shell script (libexec/git-core/git-credential-manager) that looks for git-credential-manager.exe in the PATH, picking the one with the newest mtime.

Or we teach Git itself an option to look at the mtime of all executables/scripts when looking for a git-* command that is not a built-in (we probably should only do that when the command cannot be found in libexec/git-core/, we might even allow for multiple modes where even that could be overridden).

Thoughts? Concerns?

/cc @mjcheetham

[mjcheetham]

I guess Git LFS also has a similar problem with Git for Windows preferring/resolving to the bundled version, rather than any standalone installed version? A solution that could work for both would be potentially a bonus.

It feels like we want a path resolution that looks something like this:

libexec/git-core;
%PATH%
%GIT_OPT_BUNDLED_BIN%

..where GIT_OPT_BUNDLED_BIN is some dir holding all these optional bundled binaries.

This way Git's own binaries are found first, then we go searching the user & system %PATH%s, finally resolving to the "optional" bundled binaries like GCM or Git LFS. The obvious problem with this is path length limitations.

There's also a question of moving binaries potentially being a breaking change for consumers of MinGit.

[..] picking the one with the newest mtime.

Not that I have a better solution 😉 but is mtime a reasonable solution to picking the "latest"?
Installing Git for Windows with an old GCM after the latest standalone GCM would result in the newer GCM having an older mtime, and not being preferred.

I guess we first should ask: Do we want the latest GCM/LFS to be preferred, or have the standalone versions (whatever version they are) be selected ahead of bundled copies?

If the former, then it might be better to leave this up to the bundled app itself to re-route execution to the best sibling installation. If the latter then G4W should probably just avoid calling the bundled copy if another is found on the PATH.

[dscho]

It feels like we want a path resolution that looks something like this:

libexec/git-core;
%PATH%
%GIT_OPT_BUNDLED_BIN%

I wish it was that simple, but wouldn't that break the scenario where somebody installed Git LFS to fix a problem, but that was a year ago, and now they're stuck with that Git LFS version even if Git for Windows ships with a newer version?

picking the one with the newest mtime.

Not that I have a better solution 😉 but is mtime a reasonable solution to picking the "latest"?

I guess a much better idea would be the ctime. Essentially, I would want Git to pick whichever was installed most recently.

[dscho]

Hrm. I just noticed that Git LFS is configured via

[filter "lfs"]
        clean = git-lfs clean -- %f
        smudge = git-lfs smudge -- %f
        process = git-lfs filter-process
        required = true

I fear that we'll have to add some evil hacks to support overriding the regular PATH search there.