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

From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Alex Riesen <alexander.riesen@cetitec.com>,
	git@vger.kernel.org, Eric Wong <normalperson@yhbt.net>
Subject: Re: sub-fetches discard --ipv4|6 option
Date: Tue, 15 Sep 2020 14:32:50 -0700	[thread overview]
Message-ID: <xmqqa6xqzpx9.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20200915212338.GA2868700@coredump.intra.peff.net> (Jeff King's message of "Tue, 15 Sep 2020 17:23:38 -0400")

Jeff King <peff@peff.net> writes:

> 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.