Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 25.11.18 um 15:03 schrieb Frank Schäfer:
Am 24.11.18 um 23:07 schrieb Johannes Sixt:
I don't think that there is anything to fix. If you have a file with
CRLF in it, but you did not declare to Git that CRLF is the expected
end-of-line indicator, then the CR *is* trailing whitespace (because
the line ends at LF), and 'git diff' highlights it.

Sure, it's correct to highlight it.
But it doesn't highlight it in removed lines, just in added lines.
I can see no good reason why removed and added lines should be treated
differently.

But incorrect whitespace is never highlighted in removed lines, why should CR be an exception?

1) If CR+LF line termination is used in a file, changing the content of
a line (but not its termination) currently produces a diff like

-something
+something_new^M

which causes the user to think he has changed the line ending (added a
CR) although he didn't.

But this is not limited to CR at EOL:

-<SP><TAB>something
+<SP><TAB>something_new

will also show the incorrect whitespace highlighted only for the + line.

2) If someone/something unintentionally changes the line termination
from CR+LF to LF, it doesn't show up in the diff:

-something
+something

Same here for other cases, for example

-something<SP>
+something

will not have on obvious indicator that whitespace was corrected.

If you are worried about a change in EOL style, you should better listen to your other tools. Either it is important, or it is not. If it is, they will report it to you. If it isn't, why care?

-- Hannes



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux