Re: Git push race condition?

Scott Sandler [off-list ref] writes:

It's a bare repo and I didn't realize server-side reflogs were a
thing. Just ran "git config core.logallrefupdates true" in the repo on
the server which seems to be what I should do to enable that.

That should be it, yes.

The server does know about B, it shows up when you do "git show B".
However "git branch --contains B" returns nothing.

That is "normal": git push sends objects to the object store in a
lockless manner, and then updates the reference corresponding to the
branch you're pushing to. So in case of concurrent access, the objects
may be sent, but the reference update will fail. Objects would be
garbage collected by a further "git gc [--prune]".

The "not normal" part is that the race condition on the ref update does
actually break for you.

Gitlab's update hook maintains an event log when any push event
happens, who pushed and which commits. The most recent time this
happened, the first push which was lost occured at 2014-03-24 19:04:51
and the one that overwrote it happened at 2014-03-24 19:05:04. That's
when the update hook ran, not necessarily when the user hit "git
push", but it is notable that it's 13 seconds apart which is a pretty
long time. We do run several hooks for checking coding syntax and
various other things so it's believable to me that the hooks would
take more than 13 seconds on occasion, but based on the testing I did
with the sleep hook it didn't seem like the hooks were actually the
problem.

Are you really, really, really sure that there's no force-push involved?
(either "push --force" or "push remotename +branchname")

What you describe really looks like a force-push, or a hook doing a ref
update (e.g. a hook on a dev branch that updates master if the code
passes tests or so).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/