Re: Git multiple remotes push stop at first failed connection

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 2, 2020, 16:26 UTC
Message-ID: <xmqqr1uxtow4.fsf@gitster.c.googlers.com>
In-Reply-To: <20200601214003.GA3309882@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 8 quoted lines

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