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