On Fri, May 24, 2024 at 05:34:55PM -0700, Junio C Hamano wrote: > Ian Wienand <iwienand@xxxxxxxxxx> writes: > This is a safe behaviour because the underlying command may not be > prepared to see "--help" and ignore it silently in the best case, > e.g. > > sh -c 'false "$@" || :' - --help > > that would confuse users by being totally silent, or > > sh -c 'awk "$@" || :' - --help > > that gives "awk: not an option: --help" (which is less useful than > the report of alias), The proposed patch does still print the alias expansion before trying to pass the "--help" onto the command. That was intention to be the same as "-h" behaviour. But I take your point the error message doesn't help. > or even worse yet, if the underlying command > does not understand "--help" and considers it something different, > who knows what havoc it would wreak. I guess this means that someone was relying on git to filter out --help such that it would never get to their command. To me this could probably be considered "undefined behaviour" that is probably low risk to change, but I understand the aversion to it. > For the above reason ... > > > I would propose that "--help" to a shell alias is passed through to > > the underlying command. This way you can write aliases that act more > > like the other git commands. > > ... this is a dangerous thing to do unconditionally. > > I wonder if we can come up with a notation to annotate aliases that > do support the "--help" option that wouldn't have been used by > mistake for existing aliases? We could do something like make "!!" as an alias prefix also passes this through. It seems too niche to bother with though, TBH. I could propose documenting the behaviour as-is, although that probably moves it from undefined behaviour to "this will never change". I'll take advice on what you think :) -i
