Re: [RFC PATCH v3 2/2] push: support pushing to a remote group

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 1, 2026, 16:56 UTC
Message-ID: <xmqqcy0iwrec.fsf@gitster.g>
In-Reply-To: <CAPSxiM8Nks16nJCB9N8_bi-ZmQFF71UQEzACrF+pFXKXNuVdKQ@mail.gmail.com>

Usman Akinyemi <usmanakinyemi202@gmail.com> writes:

Show 14 quoted lines

>>
>> I would personally have designed to mimic exactly like "git push r1;
>> git push r2; ..." would do (not concatenated with "&&" but with
>> ";"), which would mean that there is only one single failure mode
>> that would not affect interactions with any other remotes, but I
>> have no strong arguments to choose that design, other than that it
>> would be easy to explain when we later start supporting pushes to
>> multiple remotes in parallel, where a failure to talk to one remote
>> cannot easily affect interaction with other remotes without getting
>> affected by timing issues.
> If we want to have one failure mode i.e continue pushing when there is
> a failure,
> then, we have to use `run_command` to spawn a child process for each
> of the push.

Because you would want to avoid hitting a "die()" while pushing to the (N-1)th remote, before you push to the Nth remote?

If there is a "now we have attempted to push to all N remotes, and know the outcome from these N attempts, summarize them and present the result" phase in the program, then you'd need to spawn sub push for N times and then the primary process needs to do the summarizing.

If there isn't any such "post push clean-up" phase, we need N-1 sub pushes and the last one can be done in the primary process. If that is possible, that would be ideal, because it makes N==1 case the same as the traditional "push to a single remote" case.