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

[Alex Riesen <alexander.riesen@cetitec.com>]

Jeff King, Tue, Sep 15, 2020 17:27:30 +0200:
> 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?