Re: [PATCH v3 1/3] read-cache.c: Handle long filenames correctly
- From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
- Date
- Jul 11, 2012, 11:34 UTC
- Message-ID
- <CACsJy8A880GeyTXy9jCa6vhD-ajL29qimf5Mf94eCVjAOb-TMg@mail.gmail.com>
- In-Reply-To
- <1341998558-8502-2-git-send-email-t.gummerer@gmail.com>
On Wed, Jul 11, 2012 at 4:22 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 5 quoted lines
> Make git handle long file/path names (> 4096 characters) correctly. > > There is a bug in the current version, which causes very long > file/pathnames to be handled incorrectly, or not even added to > the index, if they share the first 4096 characters.
The patch looks correct to me though we're stepping on the border here. Linux's PATH_MAX is 4k and Git already has hard time dealing with >=4k paths (even when a single path component is less than 4k).
Show 9 quoted lines
> + >path1 && > + git update-index --add path1 && > + ( > + git ls-files -s path1 | > + sed -e "s/ .*/ /" | > + tr -d "\012" > + echo "$a" > + ) | git update-index --index-info && > +
or
BLOB=$(git hash-object -w -t blob --stdin </dev/null) git update-index --cacheinfo 100644 $BLOB $a
I don't think git cares much in these tests and using empty tree sha-1 may even work (git recognizes that sha-1 automatically), but it may hurt the reader..
-- Duy