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

From: Jeff King <peff@peff.net>
Date: Sep 30, 2018, 05:53 UTC
Message-ID: <20180930055343.GA2542@sigill.intra.peff.net>
In-Reply-To: <xmqqy3bj7dxo.fsf@gitster-ct.c.googlers.com>

On Sat, Sep 29, 2018 at 10:27:15PM -0700, Junio C Hamano wrote:

Show 20 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > 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.

Hmm. They seem quite different to me. Changing "--help" output is something that's only going to impact what the user sees (a manpage versus the alias message). And the user can follow-up by asking for what they wanted.

Whereas if I have an alias that currently understands "-h", and I do something like:

  git foo -h | wc -l

if we output to stdout, that's going to produce subtly broken results. But if we output to stderr instead, then they may see the extra message, but it's obvious what's happening, and it's probably an annoyance at worst).

Show 10 quoted lines

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

Yes, that was the intent in the behavior I laid out earlier.

-Peff