Re: [PATCH v2 2/2] File commited with CRLF should roundtrip diff and apply

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 17, 2017, 06:37 UTC
Message-ID: <xmqqk222itso.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170817060633.28491-1-tboegi@web.de>

tboegi@web.de writes:

Show 10 quoted lines

> Analyze the patch if there is a) any context line with CRLF,
> or b) if any line with CRLF is to be removed.
> Thanks to Junio C Hamano, his input became the base for the changes in t4124.
> One test case is split up into 3:
> - Detect the " a\r" line in the patch
> - Detect the "-a\r" line in the patch
> - Use LF in repo and CLRF in the worktree. (*)
>
> * This one proves that convert_to_git(&the_index,...) still needs to pass
> the &index, otherwise Git will crash.

I do not understand why you think it proves anything like that. Forget about "in repo" when you think about "git apply" without "--index/--cache". There is *NO* role the index should play in that mode.

"Otherwise Git will crash" is true, because convert_to_git() tries to dereference the istate it is given to see if there is CR in the blob that happens to be in the index at the path.

But step back and *think*. It only proves that convert_to_git() you have and/or the way read_old_data() you updated calls it after applying these two patches are still broken.

The "blob that happens to be in the index at the path" does *NOT* have anything to do with the file in the working tree that you are patching. Such an index entry may not exist (and the code would see that there is 0 CRs and 0 LFs---so what?), or it may have a blob full of CRLF, or it may have a blob full of CR not LF, or any random thing that has NO relation to the file you are patching. Why should that random blob (which may not even exist---we are discussing "git apply" without "--index/--cache" here) affect the outcome? If it does not affect the outcome, why should convert_to_git() even look at it?

It shouldn't be calling down to "has_cr_in_index(istate, path)" that is called from crlf_to_git() in the first place. The check for CR was done in the caller of convert_to_git(), i.e. read_old_data(), long before convert_to_git() is called, and the caller knows if it is (or it is not) dealing with data that needs crlf conversion at that point, based on the contents of the file being patched (which, again, does not have any relation to the blob that may or may not happen to be in the index).

Your updated caller is already telling convert_to_git() codepath when it needs CRLF and it refrains from peeking in the index with SAFE_CRLF_KEEP_CRLF flag. The bug still in the code after applying these two patches is that the other choice, i.e. SAFE_CRLF_FALSE, that is passed from read_old_data() to convert_to_git() does *not* prevent the latter from peeking into the in-core index.

And that is why "Otherwise Git will crash".