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

On Sat, Jul 26, 2025 at 09:12:55AM -0400, D. Ben Knoble wrote:

quoted

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.

This is intriguing: it would mean that an alias is not purely a
textual replacement? That's true for ! aliases today, but other than
shelling out it's pretty close.

Sort of. It's still a textual replacement for running the command. It's
just that "git foo -h" is magic that puts us into help mode, and we try
to communicate that help mode to the underlying command.

So I guess it depends on your point of view. :)

quoted

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.

And if the user actually wanted to run `bar -h`, say, because `-h`
didn't mean help for that command? I can't come up with a compelling
example, but this goes back to "textual substitution" vs. "trying to
decide what the user actually wants."

This is leaning into the idea that "git bar -h" without other arguments
should _always_ mean help. We enforce it for our own commands (via a
test script). It's not enforced for third-party commands. If somebody
found a third-party command that violated this, I'd be tempted to say
"you're doing it wrong". But that might not be feasible if it's
a command with an established history.

But I think this is already somewhat true, isn't it? If you have
alias.foo=bar, then "git foo -h" is already treated as help. René's
patch restricts that to the case of "git foo -h" and not "git foo -h
other-arg", which is good. But I don't know if we are ready to get rid
of "git foo -h" being alias-help at all.

At any rate, a (3) to consider is "--help-all": the patches I've been
working on are to make that flag work more often outside of Git
repositories. I just need to clean things up a bit and get to tests.
But if we do treat "git alias -h" specially, perhaps "--help-all" then
also warrants treatment.

Most of the special-casing of "-h" now is just recognizing it when its
alone to mean "help", even if the sub-command might recognize it as a
non-help option in other contexts. I don't think --help-all really needs
the same, since there's not much ambiguity to its meaning.

But yeah, if individual commands checked "--help-all" before insisting
on being in a repo (just like we do for "-h"), that seems like a good
improvement to me.

-Peff