Junio C Hamano <gitster@xxxxxxxxx> writes:
> Imagine that the project wants LF line endings, i.e. it considers
> that a line with CRLF ending has an unwanted "whitespace" at the
> end. Now, you start from this source file:
>
> 1 <CRLF>
> 3 <CRLF>
> 5 <CRLF>
>
> and a patch like this comes in:
>
> 1 <CRLF>
> -3 <CRLF>
> +three <CRLF>
> 5 <CRLF>
>
> You think that "3 <CRLF>" was replaced by "three <CRLF>", and the
> claim is "the 'previous' contents already had <CRLF> ending, so the
> change is not making things worse".
To see the problem with "check existing lines", it probably is
easier to extend the above example to start from a file with one
more line, like this:
1 <CRLF>
3 <CRLF>
4 <LF>
5 <CRLF>
and extend all the example patches to remove "4 <LF>" line as well,
where they remove "3 <CRLF>", making the first example patch like
so:
1 <CRLF>
-3 <CRLF>
-4 <LF>
+three <CRLF>
5 <CRLF>
Now, if you take "three <CRLF>" to be replacing "3 <CRLF>", then you
may feel that not warning on the CRLF would be the right thing, but
there is no reason (other than the fact you, a human, understand
what 'three' means) to choose "3 <CRLF>" over "4 <LF>" as the
original. If you take "three <CRLF>" to be replacing "4 <LF>", you
would need to warn.
A totally uninteresting special case is when the original is all
<CRLF>, but in that case, as you already said in the original
message, the project wants <CRLF> and you can configure it as such.
Then <CR> in the line-end <CRLF> won't be mistaken as if it is a
whitespace character <CR> at the end of a line terminated with <LF>.