From: Usman Akinyemi Date: Tue, 31 Mar 2026 22:35:12 GMT Subject: Re: [RFC PATCH v3 2/2] push: support pushing to a remote group Message-ID: In-Reply-To: > > I am not convinced that having these two "failure modes" is a good > thing; I am not convinced that a single failure mode is better, > either, though X-<. > > 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. > I did not think about deciding what approach to pick out of the two, It was just the default i.e the behaviour after adding the changes. I think it makes sense that we have one failure mode incase of multiple remotes in parallel. > > +This means the user is responsible for ensuring that the sequence of > > +individual pushes makes sense. If `git push r1`` would fail for a given > > +set of options and arguments, then `git push all-remotes` will fail in > > +the same way when it reaches r1. The group push does not do anything > > +special to make a failing individual push succeed. > > "when it reaches r1" makes it sound as if the group push then stops > after that failure, but that is not what we just read in the two > paragraphs about two failure modes. hmm, though reading the statement from the beginning makes it clear to me, if `git push r1` will fail, if you `r1` is part of `all-remotes`, if you use `git push all-remotes`, then when it reach `r1`, `r1` will also fail. I think I can make the wording better which should be clear for parallel cases also. >