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

Re: [PATCH 2/3] remote: separate the concept of push and fetch mirrors

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 31, 2011, 04:03 UTC
Message-ID
<7vfwq4kkbe.fsf@alter.siamese.dyndns.org>
In-Reply-To
<loom.20110331T044824-341@post.gmane.org>
chris <jugg@hotmail.com> writes:
Show 6 quoted lines
>> I use the mirror for synchronizing "local" work between my workstations 
>> (home/office).  So, I use the fact that I can fetch and pull from the mirror.
>
> That of course should say:
>
> So, I use the fact that I can fetch from and *push* to the mirror.

It is not quite clear what you meant by "mirror" above, but I am assuming that you meant that you have a third repository that you use for the sole purpose of synchronizing your work done in two repositories, one at home and the other at office.

The synchronizing point should be a normal remote in such a case. If you mirror-push into the mirror from home, you may lose what you have pushed from office that you forgot to pull back to home before starting to work at home via the mirror. If you mirror-fetch from the mirror from office, you may lose what you worked locally on office and forgot to push out before mirror-fetching for one thing, and for another, you will be overwriting the tip of your current branch.

Using a pure mirror in such a three-repository situation _can_ be made to work, but only if you are very careful: before you leave home, commit everything and push to the mirror and then go to office; when you come to the office, fetch from the mirror and "reset --hard" before doing anything else; before leaving office, commit everything and push to the mirror; when you come home, fetch from the mirror and "reset --hard" before doing anything. Ad infinitum...

Hopefully we are already forbidding mirror fetching into a non-bare repository, so the system is foolproofed in that direction at least to avoid such mistakes. I offhand do not remember if we protect the branch that is currently checked out from mirror pushing, though. Hopefully, receive.denycurrentbranch will protect it, but other branches may happily get rewound when you do a mirror push.

A safer and more customary way to set up the synchronization between two repositories is to arrange them to pull from each other (and if you can initiate connections only in one direction, emulate one side of "git fetch" with "git push").

In such an arrangement, a local branch "master" at home will correspond to "refs/remotes/home/master" at the office, and a local branch "master" at the office will correspond to "refs/remotes/office/master" at home. There is no mirror configuration involved.

Hopefully this will clear things up somewhat.
Previous: chrisNext: chris
Message 11 of 13 in “checkout new branch tracks wrong remote (bug?)”
  1. chrisMar 30, 2011
  2. Jeff KingMar 30, 2011
  3. 0/3 better "remote add --mirror" semanticsJeff King, Mar 30, 2011
  4. 1/3 remote: disallow some nonsensical option combinationsJeff King, Mar 30, 2011
  5. 2/3 remote: separate the concept of push and fetch mirrorsJeff King, Mar 30, 2011
  6. Junio C HamanoMar 30, 2011
  7. Jeff KingMar 30, 2011
  8. Junio C HamanoMar 30, 2011
  9. chrisMar 31, 2011
  10. chrisMar 31, 2011
  11. Junio C HamanoMar 31, 2011
  12. chrisMar 31, 2011
  13. 3/3 remote: deprecate --mirrorJeff King, Mar 30, 2011

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.