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

From: chris <jugg@hotmail.com>
Date: Mar 31, 2011, 12:59 UTC
Message-ID: <loom.20110331T140539-266@post.gmane.org>
In-Reply-To: <7vfwq4kkbe.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster <at> pobox.com> writes:

Show 5 quoted lines

> 
> chris <jugg <at> 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 from and push to the

mirror.

Show 5 quoted lines

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

Yes, I was referencing my original post from the top level thread that triggered these patches.

> The synchronizing point should be a normal remote in such a case.

I find that much more cumbersome. It is much simpler for me to generate various patch branches and before calling it a day/night put all of my pending changes into a wip branch that isn't already on another branch and push to my mirror remote - all refs are pushed. No need to concern myself with ensuring I don't forget a newly created local ref.

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

It is much more likely for me to forget to push a local ref than to forget to synchronize - the point of this activity is to continue my work in a different location, something I couldn't do if I don't synchronize. As for content in the mirror itself being lost - that is irrelevant, it is just a buffer. The home and/or work repositories have whatever is in the mirror - fetching from the mirror is where fail safes, if any, are needed.

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

yes, which is the point of my second suggestion to change the fetch refs for a mirror remote if the local repository is not bare. But generally, when intentionally fetching from a mirror I want it to overwrite whatever I have locally, probably because I *had* forgotten to push from home the night before, and subsequently re-implemented the work at the office, so when I get home the following night, I just blow away whatever I have locally with my work from the office. But that action certainly should be explicitly requested and not the default.

> Using a pure mirror in such a three-repository situation _can_ be made to
> work, but only if you are very careful:

*careful* depends on work flow. And a pure mirror approach works quite well for me in this situation, with less effort than manually managing what refs to push.

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

If you mean what I think you mean, then you are not.

>  I offhand do not remember if we protect the branch
> that is currently checked out from mirror pushing, though.

I don't know - I've only mirror pushed to a bare repository.

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

"customary" or "ideal"? I certainly won't argue the convenience of such a setup if the logistics allowed for it.

Of course the most ideal way to solve this problem would be to have a laptop. In the mean time I have a really useful tool called Git that generally has just enough rounded edges to avoid stabbing myself, but does not dumb things down to the point of being controlling. :)

chris