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