On Tue, Jun 2, 2020 at 12:26 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Jeff King <peff@xxxxxxxx> writes: > > > There's really no benefit to doing it all in a single Git process, as > > we'd connect to each independently, run a separate independent > > pack-objects for each, etc. > > > > I'd even suggest that Git implement such a loop itself, as we did for > > "git fetch --all", but sadly "push --all" is already taken for a > > different meaning (but it might still be worth doing under a different > > option name). > Yes. We notice the fetch/push --all is for branches. > I wonder if it is possible to update the implementation to do so > without changing the UI at all, though. > > The presence of the "--all" option in "fetch" command is tied > closely to the fact that it makes no sense to have multiple URLs > that are used to download from at the same time under a single > remote name (e.g. what should "remotes/origin/master" point at if > two URLs say different things if such an arrangement were allowed?). > > On the other hand, the pushURL for a single remote can be multiple > places for redundancy (a possible #leftoverbits here is that we > should probably disable the "pretend that we immediately turned > around and fetched from them after pushing" optimization when > pushing to a remote that has multiple pushURLs defined) does not > need an extra option. If the way we currently push is suboptimal > and it is better to spawn a separate "git push" instance via the > run_command() API, that can safely be done as a bugfix without > affecting any UI elements, no? > I agree a "bugfix" for push only is good enough and safe. As the current behavior is already pushing to all pushURLs of a single remote. We are not trying to change behavior or do anything extra.