On Wed, Jan 5, 2011 at 12:47, Jeff King <peff@xxxxxxxx> wrote: > > However, in the default configuration, we fetch using a "+" refspec, > which forces update of the ref even in the case of a non-fast-forward. I > don't know whether that force also would override any lock-checking. Nope, it doesn't. We still use locking to update the refs, to ensure the update is seen atomically by a reader. The + just means don't check that the old value is fully reachable from the new after the lock as been taken. If both fetch processes try to update the same ref at the same time, one will get the lock and continue, and the other will crash with an error (because the lock was busy). If one is slightly slower than the other, they will probably update the refs twice, with the slower fetch updating what the faster one had just updated. :-) -- Shawn. -- 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