Re: [PATCH 4/4] builtins: show help on "-h"/"--help-all" with more than 2 arguments left

From: D. Ben Knoble <ben.knoble+github@gmail.com>
Date: Jul 30, 2025, 21:55 UTC
Message-ID: <CALnO6CAbTjuFrLbhC24VDmdy4Utx29g92M5eYV9BPahXK+o+1A@mail.gmail.com>
In-Reply-To: <xmqqms8qzdd0.fsf@gitster.g>

On Sat, Jul 26, 2025 at 8:28 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 11 quoted lines

>
> "D. Ben Knoble" <ben.knoble+github@gmail.com> writes:
>
> > When asking for short help on a previous command, the user may use their
> > shell history to recall a command like
> >
> >     git rebase new-base
> >
> > Then inserting "-h" after "rebase" doesn't yield the help; make it so.
>
> I doubt this is a good idea for at least two reasons.

As I said in the cover letter, I think this is the most controversial and can be dropped. However…

>  * As "git help cli" says, we should be discouraging, not
>    encouraging peope to say "git rebase new-base -h".

…that's not what I'm encouraging here. Instead, it's more like below:

>  * "git rebase -h new-base" that shows help is probably a bug (think
>    what should happen with s/rebase/grep/) in the first place.

And at least according to my tests, "git grep -h new-base" still greps
rather than shows help. Compare
- "git grep -h squash" (greps squash)
- "git rebase -h @{u}" (shows help)

Show 5 quoted lines

> If anything, we probably should fix the "-h" codepath to
>
>  - react and do the short-help only when "-h" is the only command
>    line option; with argument, it should probably barf, saying "-h
>    does not take an argument".

I think we have the first half already ("argc == 2" in the preimage). I'm not interested in writing the second half right now, personally, if we end up dropping this patch, so someone else could take that up.

Show 22 quoted lines

>  - if "-h" resulted in reported an alias, it should stop there.
>    E.g. "git -c alias.x=ls-files x -h" would currently invoke "git
>    ls-files -h" after reporting that 'x' is aliased to 'ls-files'.
>    If the alias is to one of our commands, it is not too risky, but
>    otherwise we should not assume it is safe to append "-h" to the
>    underlying command and run it.  Imagine
>
>    $ git -c alias.x='!echo rm -rf .' x -h
>
>    and worse yet, if your alias did not have "echo" in it ;-)???
>
> The only end-user expectation we can safely assume is when they
> say,
>
>    $ git frotz -h
>
> is that they would get a help on 'frotz' without doing any harm.
> If frotz is an alias to some external command, for which we have no
> idea what it would do when we run it with "-h" appended to the
> command line, the user would be in a lot of pain if the aliased
> operation is destructive.
>

I think this is being discussed on another series, and I'll leave it there :)