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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 10, 2022, 18:58 UTC
Message-ID: <xmqq35bv33qk.fsf@gitster.g>
In-Reply-To: <pull.1357.git.git.1665418677535.gitgitgadget@gmail.com>

"Daniel Sonbolian via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Daniel Sonbolian <dsal3389@gmail.com>
>
> 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).

Show 9 quoted lines

> 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...