Right. Receiving that error is what happens during my testing with a hook that sleeps for 60s, and that outcome makes sense. But whatever is occurring in production must be different, since both users see successful pushes with the first one just being overwritten.
On Mon, Mar 24, 2014 at 5:16 PM, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > On Mon, Mar 24, 2014 at 8:18 PM, Scott Sandler > <scott.m.sand...@gmail.com> wrote: >> I run a private Git repository (using Gitlab) with about 200 users >> doing about 100 pushes per day. > > Ditto but about 2x those numbers. > >> error: Ref refs/heads/master is at >> 4584c1f34e07cea2df6abc8e0d407fe016017130 but expected >> 61b79b6d35b066d054fb3deab550f1c51598cf5f >> remote: error: failed to lock refs/heads/master > > I also see this error once in a while. I read the code a while back > and it's basically because there's two levels of locks that > receive-pack tries to get, and it's possible for two pushers to get > the first lock due to a race condition. > > I've never seen data loss due to this though, because the inner lock is > atomic. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
