From: John Siu <john.sd.siu@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: Git multiple remotes push stop at first failed connection
Date: Mon, 1 Jun 2020 21:32:55 -0400 [thread overview]
Message-ID: <CAGKX4vH42x7nhCgtJ80fiNeaj1ROVxc-R8gO6xV21-6D3GbQSg@mail.gmail.com> (raw)
In-Reply-To: <20200601214003.GA3309882@coredump.intra.peff.net>
Thank Jeff for replying.
Yes, one route we are looking into is use fetch -all, push -all and
wrap push tag with a loop, or may do what you suggest and wrap all 3
in a loop for consistency.
On Mon, Jun 1, 2020 at 5:40 PM Jeff King <peff@peff.net> wrote:
>
> On Sun, May 31, 2020 at 08:28:38PM -0400, John Siu wrote:
>
> > Let say my project has following remotes:
> >
> > $ git remote -v
> > git.all "server A git url" (fetch)
> > git.all "server A git url" (push)
> > git.all "server B git url" (push)
> > git.all "server C git ur" (push)
> >
> > When all serverA/B/C are online, "git push" works.
>
> A slight nomenclature nit, but that's _one_ remote that has several
> push urls.
>
> > However "git push" will stop at the first server it failed to connect.
> > So if git cannot connect to server A, it will not continue with server
> > B/C.
> >
> > In the past I have server C turn off from time to time, so failing the
> > last push is expected. However recently server A went offline
> > completely and we notice git is not pushing to the remaining 2
> > remotes.
> >
> > Not sure if this is intended behavior or can be improved.
>
> I don't think we've ever documented the error-handling semantics.
> Looking at the relevant code in builtin/push.c:do_push():
>
> url_nr = push_url_of_remote(remote, &url);
> if (url_nr) {
> for (i = 0; i < url_nr; i++) {
> struct transport *transport =
> transport_get(remote, url[i]);
> if (flags & TRANSPORT_PUSH_OPTIONS)
> transport->push_options = push_options;
> if (push_with_options(transport, push_refspec, flags))
> errs++;
> }
> } else {
> struct transport *transport =
> transport_get(remote, NULL);
> if (flags & TRANSPORT_PUSH_OPTIONS)
> transport->push_options = push_options;
> if (push_with_options(transport, push_refspec, flags))
> errs++;
> }
> return !!errs;
>
> it does seem to try each one and collect the errors. But the underlying
> transport code is so ready to die() on errors, taking down the whole
> process, that I suspect it rarely manages to do so. You're probably much
> better off defining a separate remote for each push destination, then
> running your own shell loop:
>
> err=0
> for dst in serverA serverB serverC; do
> git push $dst || err=1
> done
> exit $err
>
> 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).
>
> -Peff
next prev parent reply other threads:[~2020-06-02 1:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-01 0:28 Git multiple remotes push stop at first failed connection John Siu
2020-06-01 21:40 ` Jeff King
2020-06-02 1:32 ` John Siu [this message]
2020-06-02 16:26 ` Junio C Hamano
2020-06-02 16:54 ` John Siu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGKX4vH42x7nhCgtJ80fiNeaj1ROVxc-R8gO6xV21-6D3GbQSg@mail.gmail.com \
--to=john.sd.siu@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).