Subject: Re: [PATCH] git.c: fix, stop passing options after --help

From: Junio C Hamano <[email-masked]>
Date: Mon, 10 Oct 2022 11:58:27 -0700

"Daniel Sonbolian via GitGitGadget" <[email-masked]> writes:

> From: Daniel Sonbolian <[email-masked]>
>
> 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...