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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 15, 2020, 21:32 UTC
Message-ID: <xmqqa6xqzpx9.fsf@gitster.c.googlers.com>
In-Reply-To: <20200915212338.GA2868700@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 8 quoted lines

> So I think the best you could do is:
>
>   1. Keep two separate option lists, "parent" and "child". The parent
>      list has "--all" in it. The child list has stuff like "--ipv6".
>
>   2. Parse using the parent list with PARSE_OPT_KEEP_UNKNOWN. That lets
>      you decide whether we're in a mode that is spawning child fetch
>      processes.

Hmph, I vaguely recall discussion about cascading options[] list but do not find anything that may be involved in an implementation like that in <parse-options.h>. I agree that neither of the above is so attractive.

> I guess parse-options could provide a MAYBE_PASSTHRU flag. On the first
> parse_options() call, it would skip over any such options, leaving them
> in argv. On the second, the caller would tell it to actually parse them.

Or calling it USR1, which is a good way to make it crystal clear that parse_options() API does not do anything to it. The code like "builtin/fetch.c" can locally give it a more meaningful name with "#define PARSE_OPT_RECURSIVE PARSE_OPT_USR1". if recursive is the appropriate name for the bit in the context of the options[] array.

I agree that _F() convention that can be used across different types would be a good thing to have in the longer term, by the way.

Thanks.