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