Igor Djordjevic BugA <igor.d.djordjevic@xxxxxxxxx> writes:
> In short -- git-apply warns on applying the patch with CRLF line endings
> (new), considered whitespace errors, even when previous hunk version
> (old) has/had that very same CRLF line endings, too, so nothing actually
> changed in this regards. Even worse, it happily applies a patch with LF
> line endings (new) without any warning/hint, even though previous (old)
> line endings were CRLF, thus effectively (and silently) breaking the
> (previous) line endings.
Let me see if I understood your problem description correctly.
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".
But what if the patch was like this?
1 <CRLF>
-3 <CRLF>
+three <CRLF>
+four <CRLF>
5 <CRLF>
Do you want to warn on "four <CRLF>" because it does not have any
"previous" corresponding line?
Extending the thought further, which line do you want to warn and
which line do you not want to, if the patch were like this instead?
1 <CRLF>
-3 <CRLF>
+four <CRLF>
+three <CRLF>
5 <CRLF>
Extending this thought experiment further, you would realize that
fundamentally the concept of "previous contents" has no sensible
definition.
Incidentally, not realizing "there is no sensible definition of
'previous contents'" is a source of another often seen confusion by
new users of Git and any version control systems regarding the
"blame" feature. When given the final answer by "blame", they often
say "what content did the line have _before_ the commit blame gave
me?" As there is no sensible definition of 'previous contents' that
corresponds to the line, that question does not in general have a
sensible answer.