Unable to clone remote repository with a clone path > 255 chars

[rishabhBudhouliya]

• 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.26.0.windows.1
cpu: x86_64
built from commit: 9c98e1ccdfd839e4eaae1c2747d0088ef89d446b
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.18363.720]

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

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"

Editor Option: VIM
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled **

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

** Nothing that I can think of**

Details

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

Git Bash

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

git clone -c core.longpaths=true <repo-url>

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

A fresh repository cloned in my local file system

• What actually happened instead?

fatal: Unable to create temporary file 'C:/Users/techn/AppData/Local/Temp/mdyshjeqvvvkiotkhiimoqkhwjlmgqrdwwzhnrwlsimanqdqeutjmqcwnyprzzjftejzfjvvjknbsxoswabqdnbsbqnbnclnhbnvoewqnslobjqszcinqbpibonqbandlftxf14739883836305635481/zedtlkgruqbrdlhijcmwdltgocurldhkcxzjqlutteqqpljllmpofmhmkm/git-client-p': Filename too long

• Steps to reproduce the issue:

1. Create a directory structure with char length 246, in my case, it is:    C:/Users/techn/AppData/Local/Temp/mdyshjeqvvvkiotkhiimoqkhwjlmgqrdwwzhnrwlsimanqdqeutjmqcwnyprzzjftejzfjvvjknbsxoswabqdnbsbqnbnclnhbnvoewqnslobjqszcinqbpibonqbandlftxf14739883836305635481/zedtlkgruqbrdlhijcmwdltgocurldhkcxzjqlutteqqpljllmpofmhmkm
2. Open a Git Bash and change into this directory
3. Use git clone -c core.longpaths=true https://github.com/jenkinsci/git-client-plugin.git (18 chars)
3. The resulting clone path is 264 chars.

[rishabhBudhouliya]

This issue is in reference to the issue #2075 , I could not find a solution there, hence created a new issue.

[dscho]

git clone -c core.longpaths=true <repo-url>

Does it work if you use git -c core.longpaths=true clone <url>, i.e. put the -c before the clone command?

[rishabhBudhouliya]

No, it results with the same fatal error: Unable to create temporary file : Filename too long

There is one more observation, I have tried a git init + git fetch instead of git clone and that works, but as soon as I apply git config remote.origin.url <url>, the results is:

error: could not lock config file .git/config: Filename too long

[dscho]

And in all those cases, .git/config contains the setting core.longPaths = true, right?

I won't lie, there is a very good chance that I won't get to this anytime soon. Do you have some experience with C? I could guide you through debugging and fixing this, is the best I can do in the foreseeable future.

[rishabhBudhouliya]

.git/config doesn't contain core.longpaths = true because that also results in the error could not lock config file .git/config:Filename too long

I was applying git config --global core.longpaths = true which didn't show any error but apparently it can't access the local git config.

I only have some theoretical knowledge (college) in C. I could try it if you don't mind guiding me or point me to the right direction.

[dscho]

.git/config doesn't contain core.longpaths = true because that also results in the error could not lock config file .git/config:Filename too long

Yeah, there is a catch-22 right there. If the config itself cannot be read... because it would need the setting that's in the config... it simply won't work.

I guess that we cannot really support that use case.

However, git config --global core.longpaths true should have worked. (Note the absence of the =, that would be incorrect syntax.)

[rishabhBudhouliya]

My bad, I used git config --global core.longpaths true only.

After setting the global property, I should be able to access the local git config? That is the unexpected behavior. (git init and git fetch both work fine in the same local repository)

[dscho]

After setting the global property, I should be able to access the local git config?

I would think so, yes.

Maybe you can build Git and then run it in gdb to figure out where things go wrong? You could set a break point on builtin_error() via b builtin_error so that execution stops just before printing the error message, and you could inspect the stack trace via bt. Or you could git grep for the error message and insert open_in_gdb() before recompiling and running the command with /usr/src/git/bin-wrappers/git ....

[rishabhBudhouliya]

So I have built Git and I can run it in gdb. How am I suppose to attach the gdb to the git process I'm running from git bash?

[dscho]

How am I suppose to attach the gdb to the git process I'm running from git bash?

It is too short-lived to attach it via normal use.

If you use the open_in_gdb() method I mentioned above, that function will do it for you.

Otherwise, start the command in gdb to begin with:

GIT_DEBUGGER=1 /usr/src/git/bin-wrappers/git ...

[rishabhBudhouliya]

So here is what I tried:

Clone path: `/test/mdyshjeqvvvkiotkhiimoqkhwjlmgqrdwwzhnrwlsimanqdqeutjmqcwnyprzzjftejzfjvvjknbsxoswabqdnbsbqnbnclnhbnvoewqnslobjqszcinqbpibonqbandlftxf14739883836305635481/mdyshjeqvvvkiotkhiimoqkhwjlmgqrdwwzhnrwlsimanqdqeutjmqcwnyprzzjftejzfjvvjknbsxoswabqd` (246 chars)

Command: git init
Error stack trace:

(gdb) bt
#0  die_builtin (err=0x158f1b0 "Invalid path '%s': Filename too long",
    params=0x158f5e8 "▒9Y\001") at usage.c:64
#1  0x0000000000660c69 in die_errno (
    fmt=0x706495 <write_tree_usage+437> "Invalid path '%s'") at usage.c:211
#2  0x00000000004cd046 in strbuf_realpath (resolved=0x158f740,
    path=0x6e9374 <index_pack_usage+4052> ".git", die_on_error=1)
    at abspath.c:137
#3  0x00000000004cd29e in real_pathdup (
    path=0x6e9374 <index_pack_usage+4052> ".git", die_on_error=1)
    at abspath.c:229
#4  0x0000000000455d1d in init_db (
    git_dir=0x6e9374 <index_pack_usage+4052> ".git", real_git_dir=0x0,
    template_dir=0x0, flags=2) at builtin/init-db.c:348
#5  0x00000000004566e4 in cmd_init_db (argc=0, argv=0x1590620, prefix=0x0)
    at builtin/init-db.c:600
#6  0x000000000040305c in run_builtin (p=0x6bf4c0 <commands+1152>, argc=1,
    argv=0x1590620) at git.c:444
#7  0x0000000000403446 in handle_builtin (argc=1, argv=0x1590620) at git.c:674
#8  0x00000000004036fc in run_argv (argcp=0x158fd80, argv=0x158fd28)
    at git.c:741
#9  0x0000000000403b62 in cmd_main (argc=1, argv=0x1590620) at git.c:872
#10 0x00000000004cc8a7 in main (argc=2, argv=0x1590618) at common-main.c:52

[dscho]

Didn't you say earlier that git init does work?

[rishabhBudhouliya]

Yes, when I tried the same experiment explained in the issue description, git init and git fetch worked.
Strangely in the windows sdk environment, this is the result I am getting. git init is not working.
(I applied git config --global core.longpaths true before performing any other git operation)

I'm not sure myself if this is because of the experiment I am performing or git-for-windows fault.

[rishabhBudhouliya]

What is strange in the gdb debugging experiment, the clone path isn't even 255 chars long, it is shorter than that, it would be greater than that after cloning the remote repository (18 chars).

Would you like me to debug further?