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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html