git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Push force-with-lease with multi-URL remote

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 27, 2019, 20:57 UTC
Message-ID
<xmqqv9vnkxg1.fsf@gitster-ct.c.googlers.com>
In-Reply-To
<0DC4FE1B-90A9-414B-AFAC-E328608C4F98@chead.ca>
Christopher Head <bugs@chead.ca> writes:
Show 10 quoted lines
> On July 27, 2019 10:46:43 AM PDT, Junio C Hamano <gitster@pobox.com> wrote:
>>Christopher Head <bugs@chead.ca> writes:
>>
>>Quite honestly, the true culprit of the above story is that you are
>>letting multiple logically different remote repositories [*1*] use
>>the same single remote-tracking refes/remotes/myremote/ hierarchy.
>
> They weren’t supposed to be logically different (if I understand
> what you mean by that phrase). My intention was for the different
> URLs to be mirrors of each other,...

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.

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.

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.

Previous: Christopher HeadNext: Christopher Head
Message 4 of 12 in “Push force-with-lease with multi-URL remote”
  1. Christopher HeadJul 27, 2019
  2. Junio C HamanoJul 27, 2019
  3. Christopher HeadJul 27, 2019
  4. Junio C HamanoJul 27, 2019
  5. Christopher HeadJul 27, 2019
  6. Junio C HamanoJul 29, 2019
  7. Jeff KingJul 29, 2019
  8. Junio C HamanoJul 29, 2019
  9. Christopher HeadJul 29, 2019
  10. Jeff KingJul 29, 2019
  11. Junio C HamanoJul 29, 2019
  12. Jeff KingJul 29, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.