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

From: Johannes Sixt <j6t@kdbg.org>
Date: Dec 5, 2018, 21:31 UTC
Message-ID: <337ed78c-afd5-24ab-709b-ff74ee6b90ac@kdbg.org>
In-Reply-To: <de3bd8e1-cdd7-5fcf-0912-a216cc8cb3e9@googlemail.com>

Am 05.12.18 um 20:29 schrieb Frank Schäfer:

Show 12 quoted lines

> 
> 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:
>>> <RESET> after the CR if eol=lf but do not <RESET> 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.

Show 5 quoted lines

>> 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 <RESET> 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 <RESET> 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