win32/msys transition mishandled when invoking git subcommands

[glandium]

I'm not sure of the extent of the problem, but here's how I could reliably reproduce it, on a fresh install of msys2:

$ pacman -Suy mingw-w64-x86_64-make mingw-w64-x86_64-gettext git
$ echo foo: > foo.mk
$ echo -e \\tgit init foo >> foo.mk
$ echo -e \\tgit clone foo bar >> foo.mk
$ mingw32-make -f foo.mk -B

This fails with the following error:

ssh: Could not resolve hostname c: Name or service not known
fatal: Could not read from remote repository.

Running with trace enabled is somewhat enlightening:

$ GIT_TRACE=1 mingw32-make -f foo.mk -B
(...)
git.c: 371     trace: builtin: git 'clone' 'foo' 'bar'
Cloning into 'bar'...
run-command.c:369    trace: run_command: 'ssh' 'C' 'git-upload-pack '\''/msys64/home/glandium/foo'\'''
ssh: Could not resolve hostname c: Name or service not known
fatal: Could not read from remote repository.

Now, the reason the issue subject mentions win32/msys transition is because:

• mingw32-make -d mentions calling CreateProcess(C:\msys64\usr\bin\git.exe, ...)
• Changing the last line of foo.mk to set a dummy environment variable on the git clone command line works around the issue:

  $ echo foo: > foo.mk
  $ echo -e \\tgit init foo >> foo.mk
  $ echo -e \\tFOO= git clone foo bar >> foo.mk
  $ mingw32-make -f foo.mk -B
  (...)
  warning: You appear to have cloned an empty repository.
  done.

  In that case, mingw32-make -d mentions calling CreateProcess(C:\msys64\usr\bin\sh.exe, ...) because the dummy environment variable forces it to wrap the git command with a shell.

Interestingly, I cannot reproduce by just invoking git clone foo bar from a cmd shell with the right PATH variables set. It looks like in that case whatever is resolving the path for foo to a full absolute path resolves it to a msys path (/c/...) rather than a windows path (c:...) which seems to be what happens when mingw32-make executes git.

This may or may not be caused by the git-2.8.2-Cygwin-Allow-DOS-paths.patch patch, or something related.

[Alexpux]

Under MSYS2 always use MSYS make not MINGW make. mingw32-make is designed to run under CMD

[glandium]

I am invoking mingw32-make from cmd. I'm then invoking msys git from mingw32-make, which causes the problem. It actually worked with version 2.8.1, which is what appveyor has on its hosts before installing unrelated packages forced an upgrade of git to 2.12.0...

[glandium]

Well appveyor upgraded to 2.11.1 anyways, and that version fails too, so forcing the upgrade not to happen doesn't work around the problem.

[mati865]

You could try with https://github.com/git-for-windows/git/wiki/Install-inside-MSYS2-proper

[iongion]

@mati865 this works very well for me - why isn't this git client from git-for-windows, the default git client inside msys2 environment ? It appears to support mixed paths, both windows form and unix form.

[mati865]

@iongion I'm not the right person to answer this question.