Re: [PATCH] Re: keeping remote repo checked out?

On Mon, 28 Nov 2005, Junio C Hamano wrote:

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> >>     server$ git checkout production
> >>     work$ git checkout master
> >>     work$ git pull server production ;# merge into work's master
> >>     work$ git push server master:receive_from_work
> >>     server$ git pull . receive_from_work ;# merge into server's production
> >> 
> >> and you make sure receive_from_work is not checked out on server
> >> (or production is never pushed into) and always do fast forward
> >> and nothing else.
> >
> > That's what I'm doing currently, actually (with work pushing to 
> > "production", but server having checked out "deploy"), and I find it 
> > annoying to have to do the pull each time and have a separate head. It 
> > also means that, if the stuff on the server is set up as a hook, it'll 
> > have to do the locking against concurrent changes to the working tree in 
> > pull, which is much more complicated than checkout.
> 
> This depends on what is on the checked-out working tree and how
> it is used, but one use pattern I was imagining was actually
> much more elaborate.  I would set up two non-naked repositories
> on the server; let's call them treeR and treeP (reception and
> publish).

This is quite elaborate.

> Each work machine push into its own reception branch of treeR
> repository (so you have N reception branches for N workers).  On
> the server machine, a daemon monitors the reception branch heads
> (inotify or idle poll loop looking at mtime; the details do not
> matter), and run the git pull into "master" of treeR.  My daemon
> might want to forbid anything but fast forward for this pull, or
> might allow any clean merge. It compiles and runs testsuites
> next.  If anything fails during the above process, the owner of
> the reception branch is notified about the failure; I might even
> want to forcibly rewind her reception branch in this case to
> "master" when this happens.

This seems maximally inconvenient. If you lose a race, you only find out 
later, your reception branch is screwed up, and you have no way of finding 
out in advance that this is going to happen? It's much nicer to have 
people all push to a single branch, and tell them if they lose (i.e., the 
change wouldn't be a fast-forward).

> When everything goes well, the daemon goes to treeP and pulls
> from treeR's master into "deploy", which is checked out.  This
> procedure is the only thing that touches treeP, so this pull is
> guaranteed to be a fast forward.
> 
> The serialization happens by having a single such daemon
> running; no need to worry about locking anymore.

I'm not sure what the big deal about locking is. We do locking for 
updating everything else; I don't see a problem with having a lock for 
when git updates the working tree, so long as it doesn't need to hold some 
other lock as well at the same time (in which case we'd have to think 
about lock ordering).

(Actually, adding CHECKED_OUT would also allow pulling the current branch 
cleanly without all the special-casing in get-fetch.sh and git-pull.sh; it 
would have the predictable effect of leaving your working tree not up to 
date, but the ref it follows up to date, and the usual two-way merge in a 
pull would obviously do the right thing. Or you could just fetch, find out 
what will change with "git diff", and get the changes with "git 
checkout". In general, it would fix aliasing problems between 
refs/heads/* and HEAD.)
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html