On Fri, Jul 25, 2025 at 04:52:40PM -0700, Junio C Hamano wrote:
> 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").
> $ 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
