From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Wed, 11 Jul 2012 11:34:21 GMT
Subject: Re: [PATCH v3 1/3] read-cache.c: Handle long filenames correctly
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:
> 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).

> +       >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