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

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

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

> And the reason is really interesting: it only happens if the index file 
> has the same date as the entry in the index, in which case we end up doign 
> the "careful" check in ce_smudge_racily_clean_entry() and there the 
> "ce_modified_check_fs()" will end up re-reading the file, and if we don't 
> have the right CRLF behaviour, we will now return DATA_CHANGED.
>
> So the call-chain for this is:
>
> 	cmd_write_tree ->
> 	  write_tree ->
> 	    write_index ->
> 	      ce_smudge_racily_clean_entry -> 
> 		ce_modified_check_fs ->
> 		  ce_compare_data ->
> 		    index_fd ->
> 		      convert_to_git ->
> 			** wrong answer unless auto_crlf is set **
>
> 		and now "ce_smudge_racily_clean_entry()" will do
> 			ce->ce_size = htonl(0);
>
> and the one-liner fix I sent out is actually the right fix.
>
> This was harder to find than it should have been, because it actually 
> depends on the datestamp of the index file matching the datestamp of the 
> file in question!

Ahhhh, I forgot that we made write-tree to write back into index
because at that point we have a fully populated cache-tree.

Your analysis makes sense to me.  Thanks.