git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Christopher Head <bugs@chead.ca>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: Push force-with-lease with multi-URL remote
Date: Sat, 27 Jul 2019 14:43:06 -0700	[thread overview]
Message-ID: <C021D654-ECD4-4A23-9DE0-D272C3A3D901@chead.ca> (raw)
In-Reply-To: <xmqqv9vnkxg1.fsf@gitster-ct.c.googlers.com>

On July 27, 2019 1:57:18 PM PDT, Junio C Hamano <gitster@pobox.com> wrote:
>What I would call "logically the same" is the set of repositories
>that are synchronized at the server side, which may or may not have
>multiple URLs to reach it, but behave as if it is just a single one
>without your doing anything special.  Your wanting to actively make
>them in sync by the above definition makes them logically different
>set of repositories.  But the phrasing does not matter much.

OK, I would probably have just used one push URL in this scenario.

>One repository at a hosting service (which may iternally be
>replicated, but that is not even observable from outside) may be
>reached over https:// or ssh://, and the result of pushing to either
>one of the URLs would be observable by immediately fetching back
>from either one.  Having both URLs and trying to use either one that
>works may help under flaky proxy situation, for example.

That makes sense, I guess, if the unusable URLs can be expected to fail fast.

>In the reverse direction, I think "git fetch" supports the notion of
><group> of repositories, so that fetch from multiple remotes can be
>initiated with a single command, but I am not sure if we added the
>same <group> concept to the pushing side.  I personally want to have
>finer control, so when I push my work to multiple repositories, each
>of them are treated as totally different push targets, and a script
>controls multiple "git push" processes to each of them in parallel,
>with retries and all.  I think having multiple pushURL and pushing
>to them is sort-of OK, but what is broken in your configuration is
>that you have a single remote-tracking branch hierarchy---if you get
>rid of it, so that refs/remotes/myremote/ does not exist and does
>not get updated, I think things would work fine.

Yes, I agree, the presence of only a single remote tracking ref is what makes the use of a single remote with multiple URLs suboptimal here—it was just a better than the other options. I tend to have pretty reliable Internet connectivity, and I don’t particularly want to go writing custom scripts. I just want to use the normal push and fetch commands. Using multiple URLs on one remote is OK, though the single remote tracking ref is annoying. Using separate remotes works, but is more annoying due to having to remember to push to all of them. If I understand what remote groups are (separate remotes but you can act on all of them with one command?) then they should be perfect. However it does not look like they work for pushing. Would it make sense to add?
-- 
Christopher Head

  reply	other threads:[~2019-07-27 21:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-27 16:54 Push force-with-lease with multi-URL remote Christopher Head
2019-07-27 17:46 ` Junio C Hamano
2019-07-27 18:15   ` Christopher Head
2019-07-27 20:57     ` Junio C Hamano
2019-07-27 21:43       ` Christopher Head [this message]
2019-07-29  5:19         ` Junio C Hamano
2019-07-29 10:20 ` Jeff King
2019-07-29 13:33   ` Junio C Hamano
2019-07-29 13:47     ` Christopher Head
2019-07-29 19:20     ` Jeff King
2019-07-29 21:44       ` Junio C Hamano
2019-07-29 22:29         ` Jeff King

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=C021D654-ECD4-4A23-9DE0-D272C3A3D901@chead.ca \
    --to=bugs@chead.ca \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).