On Wed, Jan 05, 2011 at 12:51:12PM -0800, Shawn Pearce wrote: > 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. Good, that's what IMHO it _should_ do. :) > 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. :-) I assumed it would take the "old" value at the very beginning of the fetch (before talking with the remote), and then see that the ref was changed under our feet. Or does it simply do it at the end? ... goes to read code ... -Peff -- 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