"Daniel Sonbolian via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
> From: Daniel Sonbolian <dsal3389@xxxxxxxxx>
>
> Since commit c6b6d9f7d8a when passing --help option
When referring to an old work, use
$(git show -s --pretty=reference $that_commit)
I suspect that 2c6b6d9f (help: make option --help open man pages
only for Git commands, 2016-08-26) is what you meant (the author
CC'ed).
> to a Git command, we try to open that command man page, we
> do it for both commands and concepts, it is done by
> converting the entered command to a help command
> for the given Git command, for example:
>
> "git commit --help -i" into "git help --exclude-guides commit -i"
>
> But the options after --help option are also
> passed to the new command (-i option from the example)
"new command" meaning the "git help" command?
> which can lead to unexpected output, because the
> help command will try to execute those extra options.
Meaning "git commit --help -i" becomes "git help ... commit -i", and
because the command line parser of "git help" accepts dashed options
after "commit", it works just like "git help ... -i commit" does?
It is a request to read the help information for "git commit" using
the "--info" backend, right? Similarly, "git commit --help -m"
would do the manpage and "git commit --help -w" would show the
manpage in the browser?
It sounds like a sensible behaviour to me (even though relying on
the behaviour of "git help" that takes dashed options after "commit"
makes me feel somewhat dirty). So ...
> This fixed by building the argv statically, meaning
... I am not sure what you are fixing. Puzzled...
