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

From: Jeff King <peff@peff.net>
Date: Sep 26, 2018, 18:49 UTC
Message-ID: <20180926184914.GC30680@sigill.intra.peff.net>
In-Reply-To: <xmqqzhw4mgq3.fsf@gitster-ct.c.googlers.com>

On Wed, Sep 26, 2018 at 08:16:36AM -0700, Junio C Hamano wrote:

Show 24 quoted lines

> > This introduces a help.followAlias config option that transparently
> > redirects to (the first word of) the alias text (provided of course it
> > is not a shell command), similar to the option for autocorrect of
> > misspelled commands.
> 
> While I do agree with you that it would sometimes be very handy if
> "git cp --help" behaved identically to "git cherry-pick --help" just
> like "git cp -h" behaves identically to "git cherry-pick -h" when
> you have "[alias] cp = cherry-pick", I do not think help.followAlias
> configuration is a good idea.  I may know, perhaps because I use it
> all the time, by heart that "cp" is aliased to "cherry-pick" and
> want "git cp --help" to directly give me the manpage, but I may not
> remember if "co" was commit or checkout and want to be concisely
> told that it is aliased to checkout without seeing the full manpage.
> Which means you'd want some way to command line override anyway, and
> having to say "git -c help.followAlias=false cp --help" is not a
> great solution.
> 
> If we expect users to use "git cp --help" a lot more often than "git
> help cp" (or the other way around), one way to give a nicer experience
> may be to unconditionally make "git cp --help" to directly show the
> manpage of cherry-pick, while keeping "git help cp" to never do
> that.  Then those who want to remember what "co" is aliased to can
> ask "git help co".

I like that direction much better. I also wondered if we could leverage the "-h" versus "--help" distinction. The problem with printing the alias definition along with "--help" is that the latter will start a pager that obliterates what we wrote before (and hence all of this delay trickery).

But for "-h" we generally expect the command to output a usage message.

So what if the rules were:

  - "git help cp" shows "cp is an alias for cherry-pick" (as it does
    now)

  - "git cp -h" shows "cp is an alias for cherry-pick", followed by
    actually running "cherry-pick -h", which will show the usage
    message. For a single-word command that does very little, since the
    usage message starts with "cherry-pick". But if your alias is
    actually "cp = cherry-pick -n", then it _is_ telling you extra
    information. And this could even work with "!" aliases: we define
    it, and then it is up to the alias to handle "-h" sensibly.

  - "git cp --help" opens the manpage for cherry-pick. We don't bother
    with the alias definition, as it's available through other means
    (and thus we skip the obliteration/timing thing totally).

    This really only works for non-! aliases. Those would continue to
    show the alias definition.

Show 9 quoted lines

> If you have "[alias] cp = cherry-pick -n", split_cmdline discards
> "-n" and the follow-alias prompt does not even tell you that it did
> so, and you get "git help cherry-pick".  This code somehow expects
> you to know to jump to the section that describes the "--no-commit"
> option.  I do not think that is a reasonable expectation.
> 
> When you have "[alias] cp = cherry-pick -n", "git cp --help" should
> not do "git help cherry-pick".  Only a single word that exactly
> matches a git command should get this treatment.

I'm not sure I agree. A plausible scenario (under the rules I gave above) is:

  $ git cp -h
  'cp' is aliased to 'cherry-pick -n'
  usage: git cherry-pick ...

  $ git cp --help

I.e., you already know the "-n" part, and now you want to dig further. Of course one could just type "git cherry-pick --help" since you also know that, too. But by that rationale, one could already do:

  $ git help cp
  $ git help cherry-pick

without this patch at all.

-Peff