Re: [PATCH v3 6/6] commit-graph: show usage on "commit-graph [write|verify] garbage"

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jul 20, 2021, 21:17 UTC
Message-ID: <87lf60vfyn.fsf@evledraar.gmail.com>
In-Reply-To: <YPcU3LSpa/r5nFCP@nand.local>

On Tue, Jul 20 2021, Taylor Blau wrote:

Show 50 quoted lines

> On Tue, Jul 20, 2021 at 07:55:30PM +0200, SZEDER Gábor wrote:
>> On Tue, Jul 20, 2021 at 07:47:39PM +0200, SZEDER Gábor wrote:
>> > On Tue, Jul 20, 2021 at 01:39:45PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> > > Change the parse_options() invocation in the commit-graph code to make
>> > > sense. We're calling it twice, once for common options parsing, and
>> > > then for the sub-commands.
>> > >
>> > > But we never checked if we had something leftover in argc in "write"
>> > > or "verify", as a result we'd silently accept garbage in these
>> > > subcommands. Let's not do that.
>> > >
>> > > Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>> > > ---
>> > >  builtin/commit-graph.c  | 10 ++++++++--
>> > >  t/t5318-commit-graph.sh |  5 +++++
>> > >  2 files changed, 13 insertions(+), 2 deletions(-)
>> > >
>> > > diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c
>> > > index bf34aa43f22..88cbcb5a64f 100644
>> > > --- a/builtin/commit-graph.c
>> > > +++ b/builtin/commit-graph.c
>> > > @@ -104,7 +104,10 @@ static int graph_verify(int argc, const char **argv)
>> > >  	opts.progress = isatty(2);
>> > >  	argc = parse_options(argc, argv, NULL,
>> > >  			     options,
>> > > -			     builtin_commit_graph_verify_usage, 0);
>> > > +			     builtin_commit_graph_verify_usage,
>> > > +			     PARSE_OPT_KEEP_UNKNOWN);
>> > > +	if (argc)
>> > > +		usage_with_options(builtin_commit_graph_verify_usage, options);
>> >
>> > Checking 'argc' alone is sufficient to catch unsupported parameters.
>> >
>> > Using PARSE_OPT_KEEP_UNKNOWN is not only unnecessary, but arguably
>> > wrong here
>>
>> And it's wrong in 'multi-pack-index' and 'env--helper' as well.
>
> Thanks for spotting. Obviously this one is new, but the one in the midx
> builtin is my fault; I'm not sure why it's there, because it's clearly
> wrong.
>
> So we should definitely fix this instance via a reroll of this series,
> but that still leaves the others up for grabs. Ævar, are those (the ones
> in the 'multi-pack-index' and 'env--helper' builtins) something that you
> want to clean up while you're working in this area, or would you rather
> that I take care of it?
>
> I don't mind either way, just want to make sure that we don't duplicate
> effort.

I'm all for you picking it up :)

If you wanted to pick up these patches (or some of them) and partially/entirely replace this series I'd be happy with that too, i.e. if it makes conflicts etc. easier.

I just re-submitted this now because it's been staring at me in my "should re-roll at somep point" list for a while...

FWIW if you're poking at this area more generally we really could do with some standardization around these built-in sub-commands:

    git built-in --here subcommand 
    git built-in subcommand --or-here

Various commands support one or the other as some confusing amalgamation of either taking options to "built-in" and/or "subcommand". The sane thing to do is:

    git --git-options built-in --built-in-options subcommand --just-for-the-subcommand

But not everything does that, and some things that should be --git-options or --built-in-options we take as subcommand options, e.g. --object-format or whatever.