Re: [PATCH] git: show alias info only with lone -h

From: Jeff King <peff@peff.net>
Date: Jul 26, 2025, 08:12 UTC
Message-ID: <20250726081254.GA3042329@coredump.intra.peff.net>
In-Reply-To: <xmqqqzy33k1j.fsf@gitster.g>

On Fri, Jul 25, 2025 at 04:52:40PM -0700, Junio C Hamano wrote:

Show 17 quoted lines

> When it redirects to our commands, it is less risky as we aim to
> make all our commands honor a single "-h" via t0450.
> 
>    $ git -c alias.c=checkout c -h
>    'c' is aliased to 'checkout'
>    usage: git checkout [<options>] <branch>
>       or: git checkout [<options>] [<branch>] -- <file>...
> 
>        -b <branch>           create and checkout a new branch
>        -B <branch>           create/reset and checkout a branch
>    ...
>        --pathspec-from-file <file>
>                              read pathspec from file
>        --pathspec-file-nul   with --pathspec-from-file, pathspec elements are separated with NUL character
> 
> But then, it may not be such a good idea to pay attention to "do we
> have extra '-h'?" when alias expands to our commands, e.g.

Another interesting case: even for our own commands, the alias itself may add extra arguments, which confuses things further. So:

  $ git -c alias.gi='grep --cached' gi -h
  'gi' is aliased to 'grep --cached'
  fatal: no pattern given

runs git-grep, but even though the user said only "-h" the alias added another option which prevents the help-mode from activating.

In this case it is not too harmful, but you can come up with pathological cases where it actually runs a real command:

  git -c alias.grep-for-foo='grep -e foo' grep-for-foo -h

which runs a real grep.

I guess one way to deal with it would be if the user runs "foo -h", and alias.foo is "bar --other arguments", then we run just "bar -h", dropping the extra arguments provided by the alias.

(Another fun corner case: not all git-foo are our commands. But maybe it is enough to say "if you make a third-party git-foo it should probably respect bare -h as an option").

Show 14 quoted lines

>    $ git -c alias.c=checkout c -h main
>    usage: git checkout [<options>] <branch>
>       or: git checkout [<options>] [<branch>] -- <file>...
> 
>        -b <branch>           create and checkout a new branch
>        -B <branch>           create/reset and checkout a branch
>    ...
>        --pathspec-from-file <file>
>                              read pathspec from file
>        --pathspec-file-nul   with --pathspec-from-file, pathspec elements are separated with NUL character
> 
> We get the same short-help, without what alias expansion caused this
> mess, and without any indication that we lost 'main' on the command
> line.

Yeah, that is the flip side of René's patch. Right now we overly guess that "-h" means help. And after the patch, we'd sometimes under-guess that it meant help, even for commands which treat it as such. I think that may be the lesser of two evils, though; if you are asking for help then "git c -h" is the most-strict way to do it.

So IMHO the patch under discussion is a strict improvement, even though it leaves many other questionable cases unsolved. I'd also be happy if on top we did:

  1. When alias.foo="bar --options", turn "git foo -h" into "git bar
     -h", dropping "--options".

  2. When alias.foo="!bar", report only the alias and do not run "bar"
     at all. The collateral damage here would be:

        !git bar $(some_shell_magic_we_need)

     but IMHO that is not all that bad. If we report the alias content,
     the user can probably figure out which "git help" to run next.

-Peff