Cloning with long paths fails even when core.longPaths is set to true

[pluehne]

• 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?

$ git --version --build-options

git version 2.20.1.windows.1
cpu: x86_64
built from commit: 7c9fbc07db0e2939b36095df45864b8cda19b64f
sizeof-long: 4
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.17134.523]

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

> type "C:\Program Files\Git\etc\install-options.txt"

Editor Option: VIM
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: LFOnly
Bash Terminal Option: ConHost
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled

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

  Nothing that I know about.

Details

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

  I could reproduce this with both Bash and cmd.exe.

• 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.

  • Experiment 1

    1. Create a directory whose path is 248 characters long, for example, C:\Users\username\Desktop\longpath\longpathlongpathlongpath\longpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpath\longpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlo
    2. Open a Git Bash or cmd.exe and change into this directory
    3. Clone a repository whose canonical name is longer than 11 characters (resulting in a clone path with > 260 characters)

       git clone -c core.longPaths=true https://github.com/github/github-graphql-rails-example
       

  • Experiment 2

    1. Create a directory whose path is 248 characters long, for example, C:\Users\username\Desktop\longpath\longpathlongpathlongpath\longpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpath\longpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlo
    2. Open a Git Bash or cmd.exe and change into this directory
    3. Clone a repository whose canonical name is 11 characters or shorter (resulting in a clone path with ≤ 260 characters)

       git clone -c core.longPaths=true https://github.com/autodesk/hubble
       

  Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled was set to 1 initially. We tried to set it to 0, but this didn’t change the outcome in any of the experiments.

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

  My expectation would be to get a fresh clone without any errors in all of the experiments listed above.

• What actually happened instead?

  • Experiment 1 (Git Bash)

    $ git clone -c core.longPaths=true https://github.com/github/github-graphql-rails-example
    Cloning into 'github-graphql-rails-example'...
    fatal: Unable to create temporary file 'C:/Users/username/Desktop/longpath/longpathlongpathlongpath/longpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpath/longpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlo/github-grap': Filename too long

  • Experiment 1 (cmd.exe)

    git clone -c core.longPaths=true https://github.com/github/github-graphql-rails-example
    Cloning into 'github-graphql-rails-example'...
    fatal: '$GIT_DIR' too big

  • Experiment 2 (Git Bash)

    $ git clone https://github.com/Autodesk/hubble.git
    Cloning into 'hubble'...
    fatal: Unable to create temporary file 'C:/Users/username/Desktop/longpath/longpathlongpathlongpath/longpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpath/longpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlo/hubble/.git': Filename too long

  • Experiment 2 (cmd.exe)

    git clone https://github.com/Autodesk/hubble.git
    Cloning into 'hubble'...
    fatal: Unable to create temporary file 'C:/Users/username/Desktop/longpath/longpathlongpathlongpath/longpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpath/longpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlongpathlo/hubble/.git': Filename too long

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

  I don’t believe this is related to repositories with specific contents, but I tested this with https://github.com/Autodesk/hubble.git and https://github.com/github/github-graphql-rails-example.

Further Comments

I’ve read the release notes, and I understand that core.longPaths needs to be set to true in order for long paths to be supported by Git. Still, cloning fails regardless of whether this option is set (both through git config or by invoking Git with git -c core.longPaths=true ...).

I’ve seen issue #1710, which is about support for long paths in git init and git push. As the present issue affects git clone operations, I thought it best to open a new issue for this. I hope this was the right thing to do from your perspective.

Searching through the preexisting issues in this repository, it appears that setting core.longPaths to true solved the problem for many other users in the past. I’m not sure why this doesn’t appear to work in my case, and I’d appreciate any help in debugging this.

[rimrul]

This is probably fixed by 4f2dbdd. could you test if 2.21.0-rc1 solves this issue?

[pluehne]

@rimrul: Oh, that indeed sounds like it could solve my issue 🙂. Thanks for pointing this out!

So I’ll try out Git for Windows 2.21.0-rc1, and I’ll let you know whether or not this fixes my issue.

[rimrul]

That'd be great, thanks.

[dscho]

This is probably fixed by 4f2dbdd.

That commit has been in Git for Windows for quite a while now...

My guess is that it is a problem where we still do not quite have long paths support when trying to do anything.

@pluehne do you think you can transmogrify your scenario(s) into a PR that adds a regression test to, say, t2031-checkout-long-paths.sh?

[pluehne]

@dscho: Thanks for your reply. Sure, I will try to write a regression test as you suggested 🙂. I’m a bit busy right now, so might need a week or so to do that.

I’ll still try the newest release candidate in the meantime to see whether some other change fixed the issue for me.

[pluehne]

Looks like the issue persists with 2.20.1-rc.1. I’ll come back to you when I have had the time to write the regression test. Thanks for your help so far!

[dscho]

I'll stop holding my breath for that regression test ;-)

[rishabhBudhouliya]

@dscho Hi, is this issue fixed by git version 2.26.0?

[dscho]

It's supposed to. Can't you check?

[rishabhBudhouliya]

I am facing the exact same issue with git clone -c core.longpaths=true repo-url
The better way to do this would be to raise a new issue with the proper context?

[dscho]

I’ll come back to you when I have had the time to write the regression test.

@rishabhBudhouliya maybe you can?

[rishabhBudhouliya]

@dscho Sure! I'll write a regression test. Thanks for your response.

[theslava]

I have run into this issue as well while trying to use terragrunt (terraform wrapper). I think the issue stems from the fact that it is the local destination directory that is too long. I was able to clone the same repo into a shorter base directory, but unable to do so (getting the same error as at the start of this ticket). Using git 2.26.2.windows.1.

[dscho]

Yes, and it might be impossible without major work on Git and setting a registry flag (and rebooting).