René Scharfe wrote:
> Since ba5f28bf79 (ls-remote: use parse-options api) git ls-remote -h
> without any other options has shown the short help text of the command
> instead of acting as the short equivalent of --heads. Fix this
> regression by turning off internal handling of -h for repository setup,
> and option parsing, as well as the corresponding test in t0012.
>
> Reported-by: Thomas Rikl <tr...@online.de>
> Analyzed-by: Martin Ågren <martin.ag...@gmail.com>
> Signed-off-by: Rene Scharfe <l....@web.de>
> ---
> builtin/ls-remote.c | 1 +
> git.c | 2 +-
> t/t0012-help.sh | 1 +
> t/t5512-ls-remote.sh | 6 ++++++
> 4 files changed, 9 insertions(+), 1 deletion(-)
Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>
[...]
> --- a/git.c
> +++ b/git.c
> @@ -421,7 +421,7 @@ static struct cmd_struct commands[] = {
> { "interpret-trailers", cmd_interpret_trailers, RUN_SETUP_GENTLY },
> { "log", cmd_log, RUN_SETUP },
> { "ls-files", cmd_ls_files, RUN_SETUP },
> - { "ls-remote", cmd_ls_remote, RUN_SETUP_GENTLY },
> + { "ls-remote", cmd_ls_remote, RUN_SETUP_GENTLY | NO_INTERNAL_HELP },
There's only one other command that uses PARSE_OPT_NO_INTERNAL_HELP, and
that's "git archive". Does it need the same treatment?
More generally, is there a straightforward way for parse-options or
some compile-time analysis to catch if we forget to add
NO_INTERNAL_HELP to a command in the commands[] table?
Thanks,
Jonathan
