Concurrent pushes updating the same ref

[Marc Branchaud <marcnarc@xiplink.com>]

Hi all,

[ BACKGROUND: I've modified our build system to push a custom ref at the
start of each build.  The aim is to identify in the repo which revision got
built.  For us, an overall "build" consists of creating about a dozen
products, all from the same source tree.  The build system (Hudson) launches
each product's build concurrently on one or more build slaves.  Each of those
individual product builds clones the repo, checks out the appropriate
revision, and pushes up the custom ref.  (I would have liked to make the
Hudson master job push up the ref, instead of all the slave jobs, but I
couldn't find a way to do that.) ]

Usually this works:  Each slave is setting the ref to the same value, so the
order of the updates doesn't matter.  But every once in a while, the push
fails with:

fatal: Unable to create
'/usr/xiplink/git/public/Main.git/refs/builds/3.3.0-3.lock': File exists.
If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.
fatal: The remote end hung up unexpectedly

I think the cause is pretty obvious, and in a normal interactive situation
the solution would be to simply try again.  But in a script trying again
isn't so straightforward.

So I'm wondering if there's any sense or desire to make git a little more
flexible here.  Maybe teach it to wait and try again once or twice when it
sees a lock file.  I presume that normally a ref lock file should disappear
pretty quickly, so there shouldn't be a need to wait very long.

Thoughts?

		M.