Git-credential-manager-for-windows: Doesn't work with Git installed by MSYS2 Pacman

[eonj]

Almost same title, but not a duplicate of #70.

I am using MSYS2 environment and Git 2.14.1 delivered via MSYS2 Pacman command pacman -S git.

I installed GCMW set Git config credential.helper (manager) and credential.modalPrompt (true). However, GCMW doesn't work for my environment.

$ git credential-manager git: 'credential-manager' is not a git command. See 'git --help'.

It's because GCMW searches for /usr/libexec/git-core to find Git installation when GCMW installs itself.

whereis says:

$ whereis git-core git-core: /usr/lib/git-core /usr/share/git-core

So GCMW installs itself in %UserProfile%\bin. By default, current MSYS2 shell $PATH does not have the directory even if that path is added as %PATH%. (FYI, MSYS2 shell inherits Windows environment variables only if MSYS2_PATH_TYPE=inherit is set. See https://sourceforge.net/p/msys2/discussion/general/thread/dbe17030/.)

As a solution, I think it's natural for GCMW installer to search for /usr/lib/git-core also.

[whoisj]

The GCM ought not to be installed separately from Git for Windows, when it is installed by Git for Windows.

@dscho does the Git for Windows installer actually run the GCM installer? I thought it was just xcopy'ing the necessary binaries into the mingwXX/libexec/git-core folder.

[dscho]

does the Git for Windows installer actually run the GCM installer? I thought it was just xcopy'ing the necessary binaries into the mingwXX/libexec/git-core folder.

You are correct, it copies the binaries into that folder, and it then sets the appropriate config setting.

[eonj]

So how about MSYS2-installed Git, not one installed by Git for Windows? I also read README.md and Index.md, it says the installer is also for non-standard installations of Git. Current installer works well with Cygwin-installed Git.

[whoisj]

@Uni- I'm having some difficulty parsing your response, but I'll attempt to reply. Apologies if I'm misunderstanding.

I have no idea about MSYS2-installed anything. Anything provided by MSYS2 would be tracked by them, not the GCM. The GCM standalone installer should work with an Cygwin environment - somebody who uses it (I do not) came by and made the installer work for it.

Lastly, I thought MSYS was an API / abstraction layer so that POSIX applications has a snowball's chance in hell of running smoothly on Windows. I have never seen an MSYS "environment" before - can you please point me at it? I'm curious - thanks.

[eonj]

Being precise: MinGW, not MSYS, is the POSIX abstraction layer you know. MinGW GCC/toolchain compiles POSIX-compliant C/C++ source code to run in Win32, with MinGW headers -- sometimes with runtime library, but MinGW is primarily targetting to MSVCRT(6). This is what's different in MinGW from Cygwin toolchain, because Cygwin also aims to provide a full POSIX-compatibility layer and the toolchain always links to the Cygwin runtime libraries. MinGW started as a fork of Cygwin, and in fact, MinGW provides a partial compatibility layer. BTW, MSYS is a POSIX-like environment running on Windows default shell, including Bash, Make, etc., built with MinGW toolchain and MSYS tools themselves.

MSYS2 is another thing. It integrates two environment: one is MSYS2 runtime, with MSYS2 runtime libraries (forked recently from Cygwin); the other is MinGW-w64, a MinGW-like (similarly aimed) project. Both in default runs on MinTTY, a more POSIX-like shell environment than cmd; but they can also run on cmd. Here MSYS2 provides built-in Pacman installation, Pacman repositories and packages. So in MSYS2 we can install software packages of precompiled binaries, e.g. Git.

So it reduces that the problem is about the Git package of MSYS2 central repository. The package installs git.exe in /usr/bin, and git-core directory in /usr/lib (not /usr/libexec). That's the point of this issue.

For information: Git for Windows also builds on MSYS2 (See Git for Windows GitHub group repositories). The git-core is located /mingw64/libexec/git-core; Git for Windows copies the GCMW binaries to the path, so no problem there.

[dscho]

MinGW GCC/toolchain compiles POSIX-compliant C/C++ source code to run in Win32,

That is incorrect. It does not compile any POSIX-compliant C/C++ source code, for example it does not compile fork() calls.

Also, the MINGW "runtime" is actually a very small static library, so the output of MINGW GCC does not link to any MINGW .dll by default. That is the main difference to MSys/MSYS2 (and MSys is very much a thing...): the latter always link implicitly to msys-1.0.dll/msys-2.0.dll. Those runtimes are indeed very related to Cygwin's runtime, which is way more than just a library, as those runtimes perform a lot of stuff at startup already, let alone for pretty much all POSIX functionality (including fork()).

MinGW very definitely did not start as a fork of Cygwin. This is a common confusion and probably arises from the fact that MinGW applications are usually built from the MSys Bash (and MSys did start as a fork of Cygwin).

Also, MinTTY is an ANSI compliant terminal, not a shell environment.

It may not be important to clarify these inaccuracies in the context of this ticket, but it is important in other contexts to keep the facts straight.

Now for the meat of your response: it is true that MSYS2 installs the MSYS version of Git such that the stuff that should go into libexec now goes into lib instead. This is not only incorrect (read: a bug in MSYS2), but it also disagrees with Cygwin's Git (which it should imitate).

So i would rather suggest that MSYS2 users who want to use MSYS Git should work around that bug by "installing" Git Credential Manager by unpacking the .zip into an appropriate location (either /usr/lib/git-core/, or directly into /usr/bin/) and configure git config --system credential.helper manager.

BTW saying that Git for Windows builds on MSYS2 is simplifying things a bit too drastically for my taste.

[dscho]

So i would rather suggest that MSYS2 users who want to use MSYS Git should work around that bug by "installing" Git Credential Manager by unpacking the .zip into an appropriate location (either /usr/lib/git-core/, or directly into /usr/bin/) and configure git config --system credential.helper manager.

BTW one may be tempted to suggest 'why don't you simply install into the location indicated by git --exec-path, then?"

The reason why you cannot do it that way is... drumroll MSYS Git and Cygwin Git, which both report pseudo Unix paths (/usr/lib/git-core/ and /usr/libexec/git-core, respectively). Those are not valid Windows paths, and therefore it is not a solution.

[eonj]

@dscho Sorry for a bunch of inaccurate text and thank you so much for kind correction. I couldn't even imagine you'd be here!

I didn't know MSYS2 package-installed Git was doing wrong about /usr/lib/git-core instead of /usr/libexec/git-core. BTW I was thinking that it is possible for the installer to guess the Git installation path in MSYS2, as in Cygwin and using cygpath -wa. Anyway, if this is wrong and hopeless, I will close this issue.

[ebugusey]

It's probably a good idea to make GCM package for msys2 and cygwin and distribute it that way instead of an installer.

[dscho]

It's probably a good idea to make GCM package for msys2 and cygwin and distribute it that way instead of an installer.

And it's probably an even better idea that somebody who wants this relieves the maintainers from the burden to support yet another set of packages (32-bit, 64-bit, MSYS2, Cygwin).