All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "SZEDER Gábor" <szeder.dev@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] multi-pack-index: simplify handling of unknown --options
Date: Fri, 08 Jul 2022 14:08:07 -0700	[thread overview]
Message-ID: <xmqqh73ruxc8.fsf@gitster.g> (raw)
In-Reply-To: <20220708202847.662319-1-szeder.dev@gmail.com> ("SZEDER Gábor"'s message of "Fri, 8 Jul 2022 22:28:47 +0200")

SZEDER Gábor <szeder.dev@gmail.com> writes:

> Although parse_options() can handle unknown --options just fine, none
> of 'git multi-pack-index's subcommands rely on it, but do it on their
> own: they invoke parse_options() with the PARSE_OPT_KEEP_UNKNOWN flag,
> then check whether there are any unparsed arguments left, and print
> usage and quit if necessary.

The existing code check if there are any unparsed arguments or
options.  

Omitting PARSE_OPT_KEEP_UNKNOWN allows parse_options() to deal with
unknown options by complaining, but it happily leaves non-options on
the command line and reports how many of them there are.

Doesn't this patch make

	$ git multi-pack-index write what-is-this-extra-arg-doing-here

silently ignore the extra argument instead of barfing on it?

> Let parse_options() handle unknown options instead, which, besides
> simpler code, has the additional benefit that it prints not only the
> usage but an "error: unknown option `foo'" message as well.

Yes, I agree that getting rid of KEEP_UNKNOWN is a very good idea
for this reason.  But I suspect that we still need the "did we get
an extra argument we do not know what to do with?" check.

Thanks.

> Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
> ---
>  builtin/multi-pack-index.c | 20 ++++----------------
>  1 file changed, 4 insertions(+), 16 deletions(-)
>
> diff --git a/builtin/multi-pack-index.c b/builtin/multi-pack-index.c
> index 5edbb7fe86..97a87ad8cb 100644
> --- a/builtin/multi-pack-index.c
> +++ b/builtin/multi-pack-index.c
> @@ -134,10 +134,7 @@ static int cmd_multi_pack_index_write(int argc, const char **argv)
>  		opts.flags |= MIDX_PROGRESS;
>  	argc = parse_options(argc, argv, NULL,
>  			     options, builtin_multi_pack_index_write_usage,
> -			     PARSE_OPT_KEEP_UNKNOWN);
> -	if (argc)
> -		usage_with_options(builtin_multi_pack_index_write_usage,
> -				   options);
> +			     0);
>  
>  	FREE_AND_NULL(options);
>  
> @@ -176,10 +173,7 @@ static int cmd_multi_pack_index_verify(int argc, const char **argv)
>  		opts.flags |= MIDX_PROGRESS;
>  	argc = parse_options(argc, argv, NULL,
>  			     options, builtin_multi_pack_index_verify_usage,
> -			     PARSE_OPT_KEEP_UNKNOWN);
> -	if (argc)
> -		usage_with_options(builtin_multi_pack_index_verify_usage,
> -				   options);
> +			     0);
>  
>  	FREE_AND_NULL(options);
>  
> @@ -202,10 +196,7 @@ static int cmd_multi_pack_index_expire(int argc, const char **argv)
>  		opts.flags |= MIDX_PROGRESS;
>  	argc = parse_options(argc, argv, NULL,
>  			     options, builtin_multi_pack_index_expire_usage,
> -			     PARSE_OPT_KEEP_UNKNOWN);
> -	if (argc)
> -		usage_with_options(builtin_multi_pack_index_expire_usage,
> -				   options);
> +			     0);
>  
>  	FREE_AND_NULL(options);
>  
> @@ -232,10 +223,7 @@ static int cmd_multi_pack_index_repack(int argc, const char **argv)
>  	argc = parse_options(argc, argv, NULL,
>  			     options,
>  			     builtin_multi_pack_index_repack_usage,
> -			     PARSE_OPT_KEEP_UNKNOWN);
> -	if (argc)
> -		usage_with_options(builtin_multi_pack_index_repack_usage,
> -				   options);
> +			     0);
>  
>  	FREE_AND_NULL(options);

  reply	other threads:[~2022-07-08 21:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-08 20:28 [PATCH] multi-pack-index: simplify handling of unknown --options SZEDER Gábor
2022-07-08 21:08 ` Junio C Hamano [this message]
2022-07-10 15:16   ` SZEDER Gábor
2022-07-10 16:26     ` Ævar Arnfjörð Bjarmason
2022-07-10 21:54     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqh73ruxc8.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=szeder.dev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.