From: Junio C Hamano Date: Thu, 23 Aug 2007 19:44:37 GMT Subject: Re: [TESTCASE] Failing 'git am' when core.autocrlf=true Message-ID: <7vabsit4re.fsf@gitster.siamese.dyndns.org> In-Reply-To: Linus Torvalds 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.