Git GC complains about path too long on windows for files that are not checked out #2222
Comments
|
Does setting |
|
I can't recall having seen it since I enabled that setting all over the place, since I was hitting this issue, and the real in-file-system issue, in a lot of my environments However, my point is that this error should not be displayed for an operation that does not touch the real file system, this is displayed for a file that no longer exists in the checkout, it is only of the files that did exist in one of the commits, and have since been removed (but is still part of the history). GC should not restrict its internal maxium path length to an obsolete operating system specific max path length, even if that may be necessary when using the relevant, old APIs. And just in case: If this is due to GC (for some reason) actually trying to access the (now-deleted) file in the real file system, then maybe there is a different bug in the GC code? |
Ah, I missed this, and it is not actually a file that no longer exists, it is a file that never existed: Now, this seems to happen when Now, a really big question is: why does it do this? Because Does it make sense to read the attributes from the worktree? That is a splendid question for the Git mailing list. From past conversations, I would expect the answer to be: yes (because you cannot determine the gitattributes from looking at the tree objects, as there is no information about a parent tree in them, so we have to look at the Git index anyway, falling back to the worktree if no FWIW I modified the proof-of-concept to auto-tweak the path: #!/bin/sh
set -ex
rm -rf longpath toolongdirname
git init longpath
cd longpath
very_long=this/is/a/ridicoulously/very/long/path
len="$(printf "%s" "$(pwd -W)/$very_long" | wc -c)"
# Tweak it so that the path is 240 chars including work dir path
while test $(($len+5)) -lt 240
do
very_long=${very_long%/very/*}/very/very/${very_long##*/very/}
len=$(($len+5))
done
mkdir -p $very_long
>$very_long/filename.txt
git add -A
git commit -m "Added long filename"
>anormalfile.txt
git add anormalfile.txt
git commit -m "Added a normal file"
git rm $very_long/filename.txt
git commit -m "Removed long file"
cd ..
mkdir toolongdirname
cd toolongdirname
git clone ../longpath
cd longpath
GIT_TRACE=1 git gcI also added that |
|
Closing this stale ticket. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Setup
defaults?
to the issue you're seeing?
Just some old commits with long path names (created by NPM). but have had issues with that with some files in chromium, too.
Details
Git Bash
Minimal, Complete, and Verifiable example
this will help us understand the issue.
A quick and warning free gc operation
The following was printed
URL to that repository to help us with testing?
happens in any repository with this kind of long paths, if they get cloned into a directory that is too deep for the Windows path rule, even if the files are not present in the checkout
The text was updated successfully, but these errors were encountered: