Re: Git push race condition?

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

Scott Sandler <scott.m.sandler@gmail.com> 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/