* Re: [PATCH] parse-options.c: display subcommands properly in check_typos
2026-04-06 18:38 [PATCH] parse-options.c: display subcommands properly in check_typos aubrey via GitGitGadget
@ 2026-04-06 19:27 ` Junio C Hamano
0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2026-04-06 19:27 UTC (permalink / raw)
To: aubrey via GitGitGadget; +Cc: git, aubrey
"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
^ permalink raw reply [flat|nested] 2+ messages in thread