All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: chris <jugg@hotmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/3] remote: separate the concept of push and fetch mirrors
Date: Wed, 30 Mar 2011 21:03:49 -0700	[thread overview]
Message-ID: <7vfwq4kkbe.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <loom.20110331T044824-341@post.gmane.org> (chris's message of "Thu, 31 Mar 2011 02:50:01 +0000 (UTC)")

chris <jugg@hotmail.com> writes:

>> 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.

  reply	other threads:[~2011-03-31  4:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-30  2:27 checkout new branch tracks wrong remote (bug?) chris
2011-03-30 14:59 ` Jeff King
2011-03-30 19:51   ` [PATCH 0/3] better "remote add --mirror" semantics Jeff King
2011-03-30 19:52     ` [PATCH 1/3] remote: disallow some nonsensical option combinations Jeff King
2011-03-30 19:53     ` [PATCH 2/3] remote: separate the concept of push and fetch mirrors Jeff King
2011-03-30 20:45       ` Junio C Hamano
2011-03-30 20:57         ` Jeff King
2011-03-30 22:22           ` Junio C Hamano
2011-03-31  2:44             ` chris
2011-03-31  2:50               ` chris
2011-03-31  4:03                 ` Junio C Hamano [this message]
2011-03-31 12:59                   ` chris
2011-03-30 19:53     ` [PATCH 3/3] remote: deprecate --mirror 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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vfwq4kkbe.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jugg@hotmail.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.