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

2 messages from 2026-04-06 to 2026-04-06. Participants: aubrey via GitGitGadget, Junio C Hamano.
Thread: https://gitlist.dev/t/65447

## aubrey via GitGitGadget, 2026-04-06 18:38

Subject: [PATCH] parse-options.c: display subcommands properly in check_typos
Message-ID: <pull.2084.git.1775500706920.gitgitgadget@gmail.com>

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

Signed-off-by: aubymori <aubyomori@gmail.com>
---
    parse-options.c: display subcommands properly in check_typos

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

```

## Junio C Hamano, 2026-04-06 19:27

Subject: Re: [PATCH] parse-options.c: display subcommands properly in check_typos
Message-ID: <xmqqy0izanze.fsf@gitster.g>
In-Reply-To: <pull.2084.git.1775500706920.gitgitgadget@gmail.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

```
