From: Joshua Jensen <jjensen@workspacewhiz.com>
Date: Tue, 21 Sep 2010 14:40:50 GMT
Subject: Deleting of the specified ref during the post-receive hook
Message-ID: <4C98C3F2.9050006@workspacewhiz.com>

  I've recently asked whether there was a public script to act as an 
automatic 'maintainer', something akin to Gerrit's push always 
succeeding without having to pull first when using Git as a central 
repository.  I received a number of suggestions, and I have begun trial 
implementations.

My current line of thought has an auto-merging script that monitors the 
refs/for/ namespace (similar to Gerrit) and then applies --no-ff merges 
to the appropriate branch.  For instance, when the user pushes to 
refs/for/master, the post-receive hook creates a secondary ref called 
refs/for/master-SHA1-timestamp and then deletes the refs/for/master ref:

#!bin/sh
# post-receive hook
while read oldrev newrev ref
do
     case $ref in
         refs/for/*)
             timestamp=`date +%s`
             `git update-ref $ref-$newrev-$timestamp $newrev`
             `git update-ref -d $ref`
         ;;
     esac
done

If you'll pardon my lacking shell script skills (I'm open to learn!), my 
primary question concerns safety.  When receiving a ref via an SSH-based 
server (which happens to be Gitolite, but I don't think that is relevant 
here), is the post-receive hook guaranteed to be run in a lockstep 
manner?  That is, if two people push to 'refs/for/master' at the same 
time, is there a lock to process one user and then the other user?

The auto-merging script is just simple at the moment.  It runs 'git 
fetch origin refs/for/*:refs/for/*', sorts the refs/for/ entries by 
timestamp, and merges into the specified branch, emailing the user on 
success or failure (not implemented yet... I'm sure Gitolite gives me 
access to the username, but I haven't looked it up yet).

Before I go too much deeper down this path, am I way off base here?

Thanks.

Josh