On Tue, Sep 15, 2020 at 02:32:50PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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 think we just use KEEP_UNKNOWN in those cases and ignore any downsides to it. > > 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. Ah, that's a good suggestion. My earlier "USER" suggestion was tongue-in-cheek, because I think it makes the resulting options list quite confusing. But a local #define fixes that nicely. That said, it sounds from the other part of the thread like we'll need better parse-options support anyway, so this "noop flag bit" idea probably isn't a good direction anyway. -Peff
