Our software runs a git-cmd command to display the actual git home directory:
git-cmd.exe "echo %HOME% && exit"
This command answered with the correct path in 2.19.2 and earlier versions but returns nothing in 2.20.0.
After checking this problem deeply we found that now the 2.20.0 git-cmd.exe does not execute the first passed parameter. See the following easy command with multiple passed commands:
git-cmd.exe "echo 11 && echo 22 && echo 33 && exit"
The expected result is:
11
22
33
But 2.20.0 displays only:
22
33
Could you confirm the two path environment strings you have in the two versions.
Ensuring the right variant of the .exe files is run can be a big problem (especially given the issue of catching Ctrl-C in the different environments). I'm not an expert in that area but there have been on-going issues between the different interpretations about how to handle the different OS paradigms....
Hi,
This problem is not connected to the environment.
The real problem is the following:
Although you can give a command-list to the git-cmd.exe passed as one long parameter (separated by the && characters) the newer git versions (2.20.0 and 2.10.1) forget to launch the first command in the list.
(Seemingly git-cmd starts to launch the passed commands from a wrong index.)
See the following screenshot as a clear reproduction of the issue:
I can confirm.
A new snapshot is available that should fix this issue. Could I ask y'all to please test?
Hi,
I downloaded the latest snapshot: Portable Git (self-extracting .7z archive): 32-bit.
Tue, 29 Jan 2019 20:05:21 +0100 (commit 9f16cdd421)
For me it seems that the problem is not yet fixed.
I hope I downloaded a correct package as it seems that the issue is still reproducible:
Unfortunately I found still (_an additional_) problem with the parameter processing. See following picture:
If you think that this second problem is not connected to this parameter problem then I can open a new issue with it.
Darn. I wish I was aware of that before publishing Git for Windows v2.21.0-rc0. But since I did not hear anything in 8 days, I thought we're fine.
If you think that this second problem is not connected to this parameter problem then I can open a new issue with it.
I think this second problem is connected, but probably in a surprising way for you.
When you call git-cmd "some command", it executes that command, but then does not quit CMD! It is still in that CMD, and the reason why your first command is eaten is that it is considered part of the doskey command that overrides git so that git log does not pick up a git.cmd that is lying around in your current directory.
So now that you are still in that CMD, and now that git was overridden by doskey to some macro that includes your first command, it calls the correct git but with totally unwanted parameters!
If you now call exit and then git --version again, it will work.
@tuspet please re-test with v2.21.0-rc2.
Hi,
Thank you very much. Really great! It seems that the git-cmd.exe works now as expected.

The result is okay when we are in the simple cmd.exe, and when we are inside the git-cmd.exe.
See the attached picture. Thanks again!
@tuspet thanks for testing!
Most helpful comment
Hi,

This problem is not connected to the environment.
The real problem is the following:
Although you can give a command-list to the git-cmd.exe passed as one long parameter (separated by the && characters) the newer git versions (2.20.0 and 2.10.1) forget to launch the first command in the list.
(Seemingly git-cmd starts to launch the passed commands from a wrong index.)
See the following screenshot as a clear reproduction of the issue: