On Mon, Jan 16, 2017 at 2:00 PM, Jeff King <p...@peff.net> wrote: > 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. >
Would it be possible to convert the CR to a literal \r printing? Since it's pretty common to show these characters as slash-escaped? (Or is that too much of a Unix world thing?) I know I'd find \r less confusing than '?' Thanks, Jake
