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

[Junio C Hamano <junkio@cox.net>]

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

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.

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.