From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Rasmus Villemoes <rv@rasmusvillemoes.dk>, git@vger.kernel.org
Subject: Re: [PATCH] help: allow redirecting to help for aliased command
Date: Wed, 26 Sep 2018 14:49:15 -0400 [thread overview]
Message-ID: <20180926184914.GC30680@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqzhw4mgq3.fsf@gitster-ct.c.googlers.com>
On Wed, Sep 26, 2018 at 08:16:36AM -0700, Junio C Hamano wrote:
> > 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.
> 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
next prev parent reply other threads:[~2018-09-26 18:49 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-26 10:26 [PATCH] help: allow redirecting to help for aliased command Rasmus Villemoes
2018-09-26 14:37 ` Taylor Blau
2018-09-26 15:19 ` Duy Nguyen
2018-09-28 7:44 ` Rasmus Villemoes
2018-09-26 15:30 ` Junio C Hamano
2018-09-26 18:09 ` Taylor Blau
2018-09-26 18:20 ` Junio C Hamano
2018-09-26 15:16 ` Duy Nguyen
2018-09-26 15:16 ` Junio C Hamano
2018-09-26 18:12 ` Taylor Blau
2018-09-28 7:53 ` Rasmus Villemoes
2018-09-26 18:49 ` Jeff King [this message]
2018-09-26 19:31 ` Junio C Hamano
2018-09-28 8:18 ` Rasmus Villemoes
2018-09-29 8:21 ` Jeff King
2018-09-29 17:39 ` Junio C Hamano
2018-09-30 4:27 ` Jeff King
2018-09-30 5:27 ` Junio C Hamano
2018-09-30 5:53 ` Jeff King
2018-09-28 7:40 ` Rasmus Villemoes
2018-09-28 17:00 ` Junio C Hamano
2018-10-01 11:21 ` [PATCH v2 1/3] help: redirect to aliased commands for "git cmd --help" Rasmus Villemoes
2018-10-01 11:21 ` [PATCH v2 2/3] git.c: handle_alias: prepend alias info when first argument is -h Rasmus Villemoes
2018-10-03 2:16 ` Jeff King
2018-10-01 11:21 ` [PATCH v2 3/3] git-help.txt: document "git help cmd" vs "git cmd --help" for aliases Rasmus Villemoes
2018-10-03 2:18 ` Jeff King
2018-10-03 6:25 ` Rasmus Villemoes
2018-10-03 2:13 ` [PATCH v2 1/3] help: redirect to aliased commands for "git cmd --help" Jeff King
2018-10-03 6:24 ` Rasmus Villemoes
2018-10-03 7:06 ` Jeff King
2018-10-03 11:42 ` [PATCH v3 0/3] alias help tweaks Rasmus Villemoes
2018-10-03 11:42 ` [PATCH v3 1/3] help: redirect to aliased commands for "git cmd --help" Rasmus Villemoes
2018-10-05 8:19 ` Junio C Hamano
2018-10-05 10:22 ` Rasmus Villemoes
2018-10-05 16:47 ` Junio C Hamano
2018-10-03 11:42 ` [PATCH v3 2/3] git.c: handle_alias: prepend alias info when first argument is -h Rasmus Villemoes
2018-10-03 11:42 ` [PATCH v3 3/3] git-help.txt: document "git help cmd" vs "git cmd --help" for aliases Rasmus Villemoes
2018-10-04 0:10 ` [PATCH v3 0/3] alias help tweaks Jeff King
2018-10-09 11:59 ` [PATCH v4 " Rasmus Villemoes
2018-10-09 11:59 ` [PATCH v4 1/3] help: redirect to aliased commands for "git cmd --help" Rasmus Villemoes
2018-10-09 11:59 ` [PATCH v4 2/3] git.c: handle_alias: prepend alias info when first argument is -h Rasmus Villemoes
2018-10-09 11:59 ` [PATCH v4 3/3] git-help.txt: document "git help cmd" vs "git cmd --help" for aliases Rasmus Villemoes
2018-10-12 3:17 ` [PATCH v4 0/3] alias help tweaks Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180926184914.GC30680@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=rv@rasmusvillemoes.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).