From: Johannes Sixt Date: Wed, 05 Dec 2018 21:31:21 GMT Subject: Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF Message-ID: <337ed78c-afd5-24ab-709b-ff74ee6b90ac@kdbg.org> In-Reply-To: Am 05.12.18 um 20:29 schrieb Frank Schäfer: > > Am 02.12.18 um 22:22 schrieb Johannes Sixt: >> Am 02.12.18 um 20:31 schrieb Frank Schäfer: >>> With other words: >>> "If CR comes immediately before a LF, do the following with *all* lines: >>> after the CR if eol=lf but do not after the CR if >>> eol=crlf." >> >> Why? It is the pager's duty to highlight CR, IMO. If it doesn't, but >> the user wants to see them, then they are using the wrong pager or the >> wrong pager settings. > AFAIU Junios explanation it's not the pagers fault. Then Junio and I are in disagreement. IMO, Git does not have to be more clever than the pager when it comes to presentation of text. >> As far as I am concerned, I do not have any of my files marked as >> eol=crlf, but I do *not* want to see ^M in the pager. I.e., having git >> insert between CR and LF would do the wrong thing for me. >> > But doing the same thing in added lines is doing the right thing for you ? Yes, I think so. As long as I'm not telling Git that my files are CRLF when they actual are, then the CR before LF is a whitespace error. Nevertheless, I do *NOT* want Git to outwit my pager by inserting between CR and LF all the time so that it is forced to treat the lone CR like a control character that is to be made visible. > Or are you suggesting to fix the behavior of added lines instead ? > In any case, inconsistent behavior is not what we want. I'm suggesting that users who knowingly store CRLF files in the database, but do not want to see ^M in added lines have to use whitespace=cr-at-eol and that's all. I do not see inconsistency. -- Hannes