Jeff King <peff@xxxxxxxx> writes: > On Thu, Nov 12, 2020 at 11:26:25AM -0800, Chris Torek wrote: > >> On Thu, Nov 12, 2020 at 10:52 AM Jeff King <peff@xxxxxxxx> wrote: >> > If we were starting from scratch, then I think that might have been >> > nicer, because --default-remote would be implied if there is no >> > "--remote" option. And then my lazy-to-type: >> > >> > git fetch topic >> > >> > would just work. But given that we have the positional <remote> >> > parameter already, I don't think adding --remote gives much value. And >> > it raises the question of what "git fetch --remote=foo --remote=bar" >> > means (I think the answer is last-one-wins). >> >> Since `git fetch` can fetch from more than one remote, it seems to me >> to make more sense to mean "fetch from each". > > Ah, right, I forgot that --multiple existed. Without it, specifying > multiple remotes makes no sense at all. But perhaps giving multiple > --remote would implicitly specify "--multiple". That makes sense to me. > >> (This isn't necessarily an argument in favor of adding these options, >> just my suggestion for what multiple `--remote=` settings would mean.) > > Likewise. "makes sense" above mostly means I would not object to it, but > I am not advocating for it. :) I am not sure if it makes much sense, though. The "--multiple" mode of "fetch" is about running the default fetch against each of the named remotes and the idea does not mesh very well with using (possibly different) fetch refspec per each of these fetch operations. We could come up with the maximally flexible and orthogonal syntax that gives the command one or more (remote, fetch refspec) tuples and give a way to say "use the default remote" for the first component of the tuple, and a way to say "use the configured way for the remote" for the second component of the tuple. But at that point, there would just be a single syntax that can be used to drive fetches from multiple repositories, so...
