From: Jeff King <firstname.lastname@example.org> To: Junio C Hamano <email@example.com> Cc: Alex Riesen <firstname.lastname@example.org>, email@example.com, Eric Wong <firstname.lastname@example.org> Subject: Re: sub-fetches discard --ipv4|6 option Date: Tue, 15 Sep 2020 17:23:38 -0400 [thread overview] Message-ID: <20200915212338.GA2868700@coredump.intra.peff.net> (raw) In-Reply-To: <email@example.com> On Tue, Sep 15, 2020 at 01:09:10PM -0700, Junio C Hamano wrote: > > 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. > > What is this "recursive" about? Does it have much in common with > "passthru", or are they orthogonal? I agree the name is not super-descriptive. And it's a bit odd that the parse-options code itself would not care about it. It's simply a convenient bit for the calling code to use (rather than try to manage a separate array whose values correspond). It could be PARSE_OPT_USER1, but that is probably too inscrutable. :) It's sort-of similar to passthru, but not quite. The problem with passthru is that it _always_ applies to the option. We never parse it as an option itself, but rather always stick its canonicalized form into an array of strings. But for the case we're talking about here, we don't know ahead of time whether we want the passthru behavior or not. It depends on whether we see an option like "--all" (which might even come after us). 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. 3. If we are spawning, then everything in the "child" option list becomes passthru. We could either mark them as such, or really, I guess we could just pass the remainder of argv on as-is (though it might be nice to diagnose a bogus config option once in the parent rather than in each child). That would work OK. One downside is that PARSE_OPT_KEEP_UNKNOWN is inherently flaky. It doesn't know if "--foo --bar" is two options, or the option "--foo" with the value "--bar". You could solve that by leaving dummy passthru options in the "parent" list, but now we're back to having two copies. 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. -Peff
next prev parent reply other threads:[~2020-09-15 21:24 UTC|newest] Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-14 12:19 Alex Riesen 2020-09-14 19:49 ` Jeff King 2020-09-15 11:50 ` Alex Riesen 2020-09-15 11:54 ` [PATCH] Pass --ipv4 and --ipv6 options to sub-fetches when fetching multiple remotes and submodules Alex Riesen 2020-09-15 13:06 ` Jeff King 2020-09-16 4:17 ` Junio C Hamano 2020-09-16 7:27 ` Alex Riesen 2020-09-15 21:19 ` Junio C Hamano 2020-09-16 7:25 ` Alex Riesen 2020-09-15 13:05 ` sub-fetches discard --ipv4|6 option Jeff King 2020-09-15 13:54 ` [PATCH] config: option transfer.ipversion to set transport protocol version for network fetches Alex Riesen 2020-09-16 20:02 ` Jeff King 2020-09-17 8:07 ` Alex Riesen 2020-09-17 13:20 ` [PATCH] Config option to set the " Alex Riesen 2020-09-17 13:26 ` Alex Riesen 2020-09-17 13:31 ` Jeff King 2020-09-17 13:35 ` Alex Riesen 2020-09-17 14:51 ` Jeff King 2020-09-17 15:17 ` Alex Riesen 2020-12-22 19:55 ` Junio C Hamano 2021-01-07 10:06 ` Alex Riesen 2020-09-17 16:05 ` Alex Riesen 2020-09-16 20:14 ` [PATCH] config: option transfer.ipversion to set " Junio C Hamano 2020-09-16 20:18 ` Jeff King 2020-09-16 22:50 ` Junio C Hamano 2020-09-16 22:52 ` Junio C Hamano 2020-09-17 0:48 ` Jeff King 2020-09-17 0:57 ` Junio C Hamano 2020-09-16 21:35 ` Junio C Hamano 2020-09-17 14:02 ` Alex Riesen 2020-09-17 22:31 ` Junio C Hamano 2020-09-18 7:16 ` Alex Riesen 2020-09-18 16:37 ` Junio C Hamano 2020-09-21 16:39 ` Alex Riesen 2020-09-22 5:03 ` Jeff King 2020-09-17 8:04 ` Alex Riesen 2020-09-17 8:18 ` Alex Riesen 2020-09-15 14:06 ` sub-fetches discard --ipv4|6 option Alex Riesen 2020-09-15 15:27 ` Jeff King 2020-09-15 16:03 ` Alex Riesen 2020-09-16 16:32 ` Jeff King 2020-09-17 14:33 ` Alex Riesen 2020-09-22 5:08 ` Jeff King 2020-09-15 20:09 ` Junio C Hamano 2020-09-15 21:23 ` Jeff King [this message] 2020-09-15 21:32 ` Junio C Hamano 2020-09-16 16:34 ` Jeff King 2020-09-16 21:20 ` Junio C Hamano 2020-09-14 20:06 ` Junio C Hamano
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200915212338.GA2868700@coredump.intra.peff.net \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: sub-fetches discard --ipv4|6 option' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).