Re: sub-fetches discard --ipv4|6 option

From: Alex Riesen <alexander.riesen@cetitec.com>
Date: Sep 15, 2020, 16:03 UTC
Message-ID: <20200915160357.GC18984@pflmari>
In-Reply-To: <20200915152730.GA2853972@coredump.intra.peff.net>

Jeff King, Tue, Sep 15, 2020 17:27:30 +0200:

Show 21 quoted lines

> On Tue, Sep 15, 2020 at 04:06:13PM +0200, Alex Riesen wrote:
> 
> > > Yeah, that would solve the duplication problem. We could probably add a
> > > "recursive" bit to the parse-options flag variable. Even if
> > > parse-options itself doesn't use it, it could be a convenience for
> > > callers like this one. It is a little inconvenient to set flags there,
> > > just because it usually means ditching our wrapper macros in favor of a
> > > raw struct declaration.
> > 
> > Or extend the list of wrappers with _REC(URSIVE) macros
> 
> If you go that route, we have some "_F" macros that take flags. Probably
> would make sense to add it more consistently, which lets you convert:
> 
>   OPT_BOOL('f', "foo", &foo, "the foo option");
> 
> into:
> 
>   OPT_BOOL_F('f', "foo", &foo, "the foo option", PARSE_OPT_RECURSIVE);
> 
> but could also be used for other flags.

This part (marking of the options) was easy. What's left is finding out if an option was actually specified in the command-line. The ...options[] arrays are not update by parse_options() with what was given, are they?

Maybe extend struct option with a field to store given command-line argument (as it was specified) and parse_options() will update the field if PARSE_OPT_RECURSIVE is present in .flags? Is it allowed for parse_options() to modify the options array? Or is it possible to use something in parse-options.h API to note the arguments somewhere while they are parse? I mean, there are parse_options_start/step/end, can cmd_fetch argument parsing use those so that the options marked recursive can be saved for sub-fetches?