Re: What's cooking in git.git (Jan 2017, #02; Sun, 15)

> On Mon, Jan 16, 2017 at 06:06:35PM +0100, Johannes Schindelin wrote:
>
>> >      And I think that would apply to any input parameter we show via
>> >      error(), etc, if it is connected to a newline (ideally we would
>> >      show newlines as "?", too, but we cannot tell the difference
>> >      between ones from parameters, and ones that are part of the error
>> >      message).
>>
>> I think it is doing users a really great disservice to munge up CR or LF
>> into question marks. I *guarantee* you that it confuses users. And not
>> because they are dumb, but because the code violates the Law of Least
>> Surprise.
>
> I'm not sure if you realize that with stock git, the example from your
> test looks like this (at least in my terminal):
>
>   $ git.v2.11.0 rev-parse --abbrev-ref "$(printf 'CR/LF\r\n')" >/dev/null
>   ': unknown revision or path not in the working tree.
>   Use '--' to separate paths from revisions, like this:
>   'git <command> [<revision>...] -- [<file>...]'
>
> The "\r" causes us to overwrite the rest of the message, including the
> actual filename. With my patch it's:
>
>   $ git rev-parse --abbrev-ref "$(printf 'CR/LF\r\n')" >/dev/null
>   fatal: ambiguous argument 'CR/LF?': unknown revision or path not in the working tree.
>   Use '--' to separate paths from revisions, like this:
>   'git <command> [<revision>...] -- [<file>...]'
>
> I am certainly sympathetic to the idea that the "?" is ugly and
> potentially confusing. But I think it's at least a step forward for this
> particular example.
>