MinGit CLI not working if installation path is longer than 132 characters

[thenlich]

• [v] I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
  64-bit (MinGit-2.18.0-64-bit)

$ git --version --build-options
git version 2.18.0.windows.1
cpu: x86_64
built from commit: cd1a74fc9dc8a07626c216940db9a51f25206e03
sizeof-long: 4

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
  Windows Version 10.0.15063 Build 15063 (64-bit)

$ cmd.exe /c ver
Microsoft Windows [Version 10.0.15063]

• What options did you set as part of the installation? Or did you choose the
  defaults?
  none

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

** insert your machine's response here **
n/a

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

The installation path is 133 characters long (C:\Temp\am_Files__x86__Microsoft_Visual_Studio_2017_WDExpress_Common7_IDE_CommonExtensions_Microsoft_TeamFoundation_Team_Explorer_Git)

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

CMD

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

setlocal
set DIR2=C:\Temp\am_Files__x86__Microsoft_Visual_Studio_2017_WDExpress_Common7_IDE_CommonExtensions_Microsoft_TeamFoundation_Team_Explorer_Git
"C:\Program Files\7-Zip\7z.exe" -o%DIR2% x MinGit-2.18.0-64-bit.zip

cd /d c:\temp
mkdir test.git
mkdir remote.git

set PATH=%DIR2%\cmd
git --version --build-options

git init test.git
git --bare init remote.git
cd test.git
git config user.email test@example.com
git config user.name Test

git remote add origin c:\temp\remote.git
echo > test.c
git add .
git commit -m TestMessage
git push origin master

• What did you expect to occur after running these commands?

Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 234 bytes | 117.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To c:\temp\remote.git
 * [new branch]      master -> master

• What actually happened instead?

error: cannot spawn sh: No such file or directory
fatal: unable to fork

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

n/a

[thenlich]

Note 1: the exact maximum path length seems to depend on the specific system or environment (I found at my primary system the bug occurs if the path is 100 characters long or more, or 115 characters on another account on the same machine).

Note 2: Here is another minimal example:

setlocal
set DIR2=C:\Temp\am_Files__x86__Microsoft_Visual_Studio_2017_WDExpress_Common7_IDE_CommonExtensions_Microsoft_TeamFoundation_Team_Explorer_Git
"C:\Program Files\7-Zip\7z.exe" -o%DIR2% x MinGit-2.18.0-64-bit.zip
set PATH=%DIR2%\cmd
git web--browse

• What did you expect to occur after running these commands?

usage: git web--browse [--browser=browser|--tool=browser] [--config=conf.var] url/file ...

• What actually happened instead?

fatal: 'web--browse' appears to be a git command, but we were not
able to execute it. Maybe git-web--browse is broken?

[dscho]

Is this happening for all Git commands, or only for those implemented as Unix shell scripts? (You could use git ls-remote on an HTTPS remote to test this, for example, as git-remote-https.exe is most definitely not a Unix shell script).

[thenlich]

git remote add origin https://github.com/git-for-windows/git.git
git ls-remote

• What did you expect to occur after running these commands?

From https://github.com/git-for-windows/git.git
07e862c150940f305140f052a205eb75cefa9a4b        HEAD
...

• What actually happened instead?

git: 'remote-https' is not a git command. See 'git --help'.

[dscho]

I identified the problem. We use PathAppend() to append to a path list. And PathAppend() seems to test for the maximal path length, but when we add both <GIT>\mingw64\bin and <GIT>\usr\bin, we run over already when <GIT> is about half the allowed size.

Working on it.

[thenlich]

This bug was discovered in Microsoft Visual Studio 2017. Any chance this bugfix will make it into a future Visual Studio 2017 update?

[dscho]

@thenlich good point.

[dscho]

@thenlich actually, I don't think that the fixed bug should affect VS 2017, as it does not go through the Git wrapper but calls the correct git.exe directly. Is there a bug you experience directly in Team Explorer? If so, could you please describe it in detail?

[thenlich]

The bug is just as described here: "The Git included with Microsoft Visual Studio Express 2017 for Windows Desktop (15.7.5) cannot be used from the command-line because the installation path is too long."

When working in Team Explorer, everything works as expected.

I would expect to be able to use the Git included in VS (currently v2.14.4(2)) from the command-line or in self-written scripts, and not have to install a separate instance of MinGit.

Requesting a backport.

[dscho]

I would expect to be able to use the Git included in VS (currently v2.14.4(2)) from the command-line or in self-written scripts, and not have to install a separate instance of MinGit.

The idea of including MinGit in VS is to have a private copy of Git, for the specific purpose of being used by Team Explorer. As such, it is already reduced dramatically in what it supports: in particular, MinGit does not support interactive usage.

Please also note that I consider pretty much all about MinGit included in VS as implementation detail: the target architecture, the exact location within VS' directory structure, what binaries are shipped, etc.

For example, the commands in usr\bin that are not required by the Git functionality used by Team Explorer are fair game: they might go away in any future update, and if your scripts rely on it, they do so at your own risk. Things like awk.exe might simply go missing, and it won't be a bug.

For that reason, it is highly recommended to install a real Git for Windows if you want to use it yourself.

The next MinGit update in VS will most likely have a backport of this bug fix, but it is nowhere as urgent as you make it sound.

[thenlich]

Point taken.