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

[chris <jugg@hotmail.com>]

Junio C Hamano <gitster <at> pobox.com> writes:
> 
> 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.
> 
> 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