clone fails on long paths.

[jtnord]

git clone fails if paths are too long, even if core.longpaths is enabled and the kernel has enabled long paths.

a git init, remote fetch and checkout work.

steps to reproduce

enable kernel long path support
configure git core.longpaths globally
make a directory with whose full path is over 256 characters
attempt to clone a repository

expected results

the clone is made

actual results

the clone fails
depending on the length of the directory, it can fail straight away or it can file when trying to write some .git reference objects

notes

> D:\s\t\aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >  echo %Cd%
D:\source\temp\aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

❯ git clone https://github.com/jenkins-infra/helpdesk
Cloning into 'helpdesk'...
fatal: '$GIT_DIR' too big

individual steps showing that this should work

❯ mkdir heldesk

❯ cd heldesk\

❯ git init
Initialized empty Git repository in D:/source/temp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/heldesk/.git/

❯ git remote add origin https://github.com/jenkins-infra/helpdesk

❯ git fetch origin
remote: Enumerating objects: 677, done.
remote: Counting objects: 100% (389/389), done.
remote: Compressing objects: 100% (257/257), done.
remote: Total 677 (delta 242), reused 198 (delta 131), pack-reused 288 (from 1)
Receiving objects: 100% (677/677), 148.46 KiB | 7.81 MiB/s, done.
Resolving deltas: 100% (283/283), done.
From https://github.com/jenkins-infra/helpdesk
 * [new branch]      main       -> origin/main
 * [new tag]         infra-team-sync-2022-07-08_1 -> infra-team-sync-2022-07-08_1
 * [new tag]         infra-team-sync-2022-07-12_2 -> infra-team-sync-2022-07-12_2
 * [new tag]         infra-team-sync-2022-07-19_4 -> infra-team-sync-2022-07-19_4
 * [new tag]         infra-team-sync-2022-07-26_8 -> infra-team-sync-2022-07-26_8
 * [new tag]         infra-team-sync-2022-08-02_9 -> infra-team-sync-2022-08-02_9
 * [new tag]         infra-team-sync-2022-08-09_10 -> infra-team-sync-2022-08-09_10
 * [new tag]         infra-team-sync-2022-08-16_11 -> infra-team-sync-2022-08-16_11
 * [new tag]         infra-team-sync-2022-08-23_12 -> infra-team-sync-2022-08-23_12
 * [new tag]         infra-team-sync-2022-08-30_13 -> infra-team-sync-2022-08-30_13
 * [new tag]         infra-team-sync-2022-09-06_19 -> infra-team-sync-2022-09-06_19
 * [new tag]         infra-team-sync-2022-09-13_20 -> infra-team-sync-2022-09-13_20
 * [new tag]         infra-team-sync-2022-09-20_21 -> infra-team-sync-2022-09-20_21
 * [new tag]         infra-team-sync-2022-10-04_22 -> infra-team-sync-2022-10-04_22
 * [new tag]         infra-team-sync-2022-10-11_24 -> infra-team-sync-2022-10-11_24
 * [new tag]         infra-team-sync-2022-10-18_26 -> infra-team-sync-2022-10-18_26
 * [new tag]         infra-team-sync-2022-10-25_27 -> infra-team-sync-2022-10-25_27
 * [new tag]         infra-team-sync-2022-11-08_28 -> infra-team-sync-2022-11-08_28
 * [new tag]         infra-team-sync-2022-11-15_29 -> infra-team-sync-2022-11-15_29
 * [new tag]         infra-team-sync-2022-11-22_30 -> infra-team-sync-2022-11-22_30
 * [new tag]         infra-team-sync-2022-11-29_31 -> infra-team-sync-2022-11-29_31
 * [new tag]         infra-team-sync-2022-12-06_33 -> infra-team-sync-2022-12-06_33

❯ git checkout origin/main
Note: switching to 'origin/main'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 88bd27b Merge pull request #4305 from jenkins-infra/dependabot/github_actions/tibdex/github-app-token-2.1.0

git version: git version 2.46.0.windows.1 (but I saw nothing in release notes about this being fixed).

[dscho]

This is most likely a duplicate of #3372. See in particular #3372 (comment) for an explanation why the problem occurs.

Also, see #3372 (comment) for a description how this would have to be fixed. Yes, it is involved. Yes, it will require a dedicated volunteer to do it.

[jtnord]

TBH - I do not see why longPaths is even opt in.. if the OS is configured to support it is should be used, then voila.
And yes some tools may not work - but well that is those tools problems not git!
Then the comment about needing long file support to read the config is moot.

[dscho]

I do not see why longPaths is even opt in..

Performance reasons. Turning every path into an absolute one that is prefixed with the \\?\ prefix not only takes time, it also adds additional processing requirements to resolve the path. I forgot the details, but the slow-down was substantial enough to reject any demand to turn it on by default. Feel free to perform your own experiments.

And yes some tools may not work - but well that is those tools problems not git!

That's not how I run Git for Windows, though. I would feel quite careless if I said something like this.

Now, I did lay out what needs to be done to address this fully. Given our conversation, I get the impression that you're not exactly eager to do anything about it. Is my impression incorrect?

[jtnord]

Given our conversation, I get the impression that you're not exactly eager to do anything about it. Is my impression incorrect?

I am happy to make long file support the default (and then let users opt out of it if they wish at a global level (or repo) but you have said no to that. (which would potentially entail using long file support to read the initial config)

[dscho]

I am happy to make long file support the default

Right, that's what I thought. I had made it clear that that's not going to happen on my watch, specifying reasons why that is the case, and you go ahead and ignore those reasons.

[jtnord]

, but the slow-down was substantial enough to reject any demand to turn it on by default

I have been using longpaths for multiple years and the performance has been perfectly acceptable. Perhaps there are specific scenarious for some certain repos, would you remember what you where testing with?

I am curious are you running with this enabled on your environment, if not have you tried it in the real world?

I would urge you to not close this as not planned - you may not plan on fixing it, but it is a valid bug and when searching if there are no open issues people will waste time (yours included) by filing duplicates.