Re: git-apply: warn/fail on *changed* end of line (eol) *only*?
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 26, 2016, 03:25 UTC
- Message-ID
- <xmqqvau7cqy1.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <ac97f925-d930-0592-0a2a-66c9218b1417@gmail.com>
Igor Djordjevic BugA <igor.d.djordjevic@gmail.com> writes:
Show 7 quoted lines
> 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.