Re: [PATCH] help: allow redirecting to help for aliased command

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 30, 2018, 05:27 UTC
Message-ID: <xmqqy3bj7dxo.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20180930042735.GA32120@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 13 quoted lines

> And I think this has to be stderr. We're polluting the output of the
> aliased command with our extra message, so we have two choices:
>
>   1. Pollute stderr, and risk copious stdout (or a pager) scrolling it
>      off the screen.
>
>   2. Pollute stdout, at which point our message may be confused as part
>      of the actual output of the command (and that may not even be
>      immediately noticed if it is passed through a shell pipeline or
>      into a file).
>
> Choice (2) seems like a regression to me. Choice (1) is unfortunate in
> some cases, but is no worse than today's behavior.

I think the output of "git foo -h" changing (i.e. has "aliased to..." message in front) is about the same degree of regression as "git foo --help" no longer giving "aliased to..." information anywhere, though.

Show 14 quoted lines

>> Even the first two "better" cases share the same glitch if the "foo
>> ...
>> thing to do is to
>> 
>> 	$ git unknown-command -h >&2 | less
>> 
>> And at that point, it does not matter which between the standard
>> output and the standard error streams we write "unknown-command is
>> aliased to ...".
>
> Yeah. I think if "git foo -h" produces a bunch of output you didn't
> expect, then "git help foo" or "git foo --help" may be the next thing
> you reach for. That's not so different than running the command even
> without any aliases involved.

Hmmm. With the "teach 'git foo -h' to output 'foo is aliased to bar' to the standard error before running 'git bar -h'", plus "'git foo --help' now goes straight to 'git bar --help'", "git foo --help" no longer tells us that foo is aliased to bar. Presumably "git help foo" will still give "foo is bar" and stop?