Re: [TESTCASE] Failing 'git am' when core.autocrlf=true

[Junio C Hamano <gitster@pobox.com>]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Thu, 23 Aug 2007, Marius Storm-Olsen wrote:
>> 
>> I have an issue with git-rebase failing on a repository using
>>     core.autocrlf=true
>> 
>> I've tracked it down to git-am failing with core.autocrlf=true and passing
>> with core.autocrlf=false. I've tried digging deeper into the code, but for
>> some reason ce_match_stat_basic() (read-cache.c:~187) reports the size of the
>> file in the index to be 0 (when core.autocrlf=true), which is why git-am bails
>> out on the patch. (ce->ce_size == 0, while st->st_size == the correct size on
>> disk)
>
> Very interesting.
> ...
> 	trace: built-in: git 'apply' '--allow-binary-replacement' '--index' '.dotest/patch'
> 	trace: built-in: git 'diff' '--quiet'
> 	trace: built-in: git 'diff' '--quiet'
> 	trace: built-in: git 'write-tree'
> 	trace: built-in: git 'diff' '--quiet'
>
> ie everything was fine after the "apply" phase, but the index and the 
> working tree went out-of-kilter after "git write-tree".
>
> The reason? "git write-tree" doesn't read the config file, so it never 
> even reads the "core.autocrlf=true" variable. As a result, it seems to 
> screw up the index matching when it does the cache_tree_fully_valid() 
> (which will fail due to "git apply --index" having invalidated the tree 
> SHA1's) followed by cache_tree_update().
>
>> Can anyone please enlighten me on why this may happen?
>
> This patch should fix it. 
>
> Junio - it fixes the test for me, but quite frankly, I don't see why 
> write-tree would *ever* change any non-tree index entries. But it does. I 
> think there's another bug somewhere, or I'm missing something.

As you said, there is something else going on.  write-tree is
about reading the index entries and writing them out as a set of
trees, and at that point it should not even matter if you have
garbage in the work tree or if you do not even have a work tree.
All the crlf conversions have been done when the object hit the
index, so its reading or not reading core.autocrlf should not
change its behaviour.