On Sat, Jul 26, 2025 at 09:12:55AM -0400, D. Ben Knoble wrote: > > 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. :) > > 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
