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

From: Junio C Hamano <junkio@cox.net>
Date: Nov 29, 2005, 07:52 UTC
Message-ID: <7v8xv7lwlr.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0511290141220.25300@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

Show 16 quoted lines

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