On Mon, Jul 28, 2025 at 06:43:16AM -0700, Junio C Hamano wrote: > > 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. > > It is much simpler and saner to just stop after giving the alias > expansion, isn't it? Nobody can get hurt if we did so; doing > anything else would be driving us into further corner cases that > would either confuse or harm the users. Yeah, my suggestion was assuming that it is very valuable for "git foo -h" to not only print out the alias but to automatically print git-bar's help output. I don't know if people would miss it or not. But... > > 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". > > This smells like piling more voodoo magic on top, which I am not > enthused. > > > 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. > > This I very much like, and further, I would prefer to do this for > all aliases. ...yeah, after having slept on it, I am tempted to say that it is not that valuable. And the best thing is to just stop running the sub-command automatically entirely, whether shell-based or not. -Peff
