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

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