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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 26, 2018, 19:31 UTC
Message-ID: <xmqqy3bojbs4.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20180926184914.GC30680@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 10 quoted lines

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

With that additional rule, I can buy "it is fine for 'git cp --help' to completely ignore -n and behave as if 'git help cherry-pick' was given", I think. People already expect "git cp --help" to give the alias expansion, so to them any change will be a regression any way we cut it---but I think this is the least bad approach.

>   $ git cp --help
>
> I.e., you already know the "-n" part, and now you want to dig further.

One very good thing about the "make '--help' go directly to the manpage, while teaching '-h' to report also alias expansion" is that people already expect "-h" is more concise than "--help". The current output from "git cp --help" violates that expectation, and the change you suggest rectifies it.

> Of course one could just type "git cherry-pick --help" since you also
> know that, too.

Yeah, but that is not an argument. The user aliased cp because cherry-pick was quite a mouthful and do not want to type "git cherry-pick --help" in the first place.