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

From: Jeff King <peff@peff.net>
Date: Jul 29, 2025, 07:23 UTC
Message-ID: <20250729072345.GC1426859@coredump.intra.peff.net>
In-Reply-To: <CALnO6CA2qSYePJzqXjdW6c2zC4KQJSKzsCFCzc9si0OJ8E_ohw@mail.gmail.com>

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

Show 14 quoted lines

> > 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. :)

Show 19 quoted lines

> > 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.

Show 5 quoted lines

> 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