Ian Wienand <iwienand@xxxxxxxxxx> writes:
> In trying to make some aliases more consistent in an internal tool, I
> implemented both -h/--help in the underlying command for a shell
> alias, and was a bit surprised when "git <alias> -h" worked but "git
> <alias> --help" didn't.
Yeah, with
alias.lg=log --oneline
alias.lgm=!sh -c 'GIT_NOTES_REF=refs/notes/amlog git log "$@" || :' -
"git lg -h" reports the alias, "git lg --help" does the same as "git
log --help", "git lgm -h" reports the alias, but "git lgm --help"
refrains from doing
sh -c 'GIT_NOTES_REF=refs/notes/amlog git log "$@" || :' - --help
and instead does the same as "git lgm -h" to report the alias.
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), or even worse yet, if the underlying command
does not understand "--help" and considers it something different,
who knows what havoc it would wreak.
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?
