Re: [TESTCASE] Failing 'git am' when core.autocrlf=true
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 23, 2007, 19:44 UTC
- Message-ID
- <7vabsit4re.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <alpine.LFD.0.999.0708231153150.30176@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 26 quoted lines
> 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.