Re: [PATCH] parse-options.c: display subcommands properly in check_typos

[Junio C Hamano <gitster@pobox.com>]

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

> From: aubymori <aubyomori@gmail.com>
>
> Before this, mistyping a subcommand with one dash (e.g. `git stash -list`)
> would display a message telling the user to try it with two dashes.
> Since subcommands are parsed with no dashes, this is incorrect and simply
> results in the help message for that command being shown.
>
> This commit changes check_typos to check the command type and display a
> proper message for subcommands.

The usual way to compose a log message of this project is to

 - Give an observation on how the current system works in the
   present tense (so no need to say "Currently X is Y", or
   "Previously X was Y" to describe the state before your change;
   just "X is Y" is enough), and discuss what you perceive as a
   problem in it.

 - Propose a solution (optional---often, problem description
   trivially leads to an obvious solution in reader's minds).

 - Give commands to somebody editing the codebase to "make it so",
   instead of saying "This commit does X".

in this order.

So, "Before this, " is unneeded, "This commit changes" should be
more like

    Make check_typoes() check the command type and show a proper
    message for subcommands.

Also it would want a new test to cover this case somewhere.  I am
not sure where, though perhaps a new test in t0040 with update to
t/helper/test-parse-options.c or something like that.

This is a tangent, but I was hoping that "git stash lost" or "git
remote got-url origin" would get their misspelt subcommand names
corrected with this fix, but that is not what this patch alone can
do, because all calls to check_typos() in parse_options_step() are
gated with (*arg == '-') and cannot kick in for these two examples.
parse_options_step() instead routes such input to parse_nodash_opt()
and there is no such typo correction there.

It is not so surprising that nobody has complained about this, as I
understand that the condition to trigger this is rather narrow.  You
have to give a single '-' (not two, only one) before a subcommand
that usually is spelled without any dash in front in order to
trigger it?

Thanks.

> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2084%2Faubymori%2Fmaster-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2084/aubymori/master-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/2084
>
>  parse-options.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/parse-options.c b/parse-options.c
> index a676da86f5..2c4530bb8c 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -633,7 +633,10 @@ static void check_typos(const char *arg, const struct option *options)
>  		if (!options->long_name)
>  			continue;
>  		if (starts_with(options->long_name, arg)) {
> -			error(_("did you mean `--%s` (with two dashes)?"), arg);
> +			if (options->type == OPTION_SUBCOMMAND)
> +				error(_("did you mean `%s` (with no dash)?"), arg);
> +			else
> +				error(_("did you mean `--%s` (with two dashes)?"), arg);
>  			exit(129);
>  		}
>  	}
>
> base-commit: 2855562ca6a9c6b0e7bc780b050c1e83c9fcfbd0