git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Git push race condition?

From
Scott Sandler <scott.m.sandler@gmail.com>
Date
Mar 24, 2014, 19:18 UTC
Message-ID
<CAAyEjTN53+5B9Od9wW698wODNL3hR6Upot8-ZLwEksn3ir_zjA@mail.gmail.com>
Hi folks,

I run a private Git repository (using Gitlab) with about 200 users doing about 100 pushes per day.

I've noticed that a few times in the past several weeks, we've had events where pushes have been lost when two people pushed at just about the same time. The scenario is that two users both have commits based on commit A, call them B and B'. The user with commit B pushes at about the same time as the user who pushes B'. Both pushes are determined to be fast-forwards and both succeed, but B' overwrites B and B is no longer on origin/master. The server does have B in its .git directory but the commit isn't on any branch.

I'm confident nobody is force pushing (we have a hook to disallow it on master branches and I've seen screenshots of both user's clients after they pushed). Both git clients say "successfully pushed A..B master -> master" (or A..B') in the output of their push commands. However, when the user that had B does a fetch, it shows master as having been force updated.

We have a few pre-receive hooks and post-receive hooks that run on pushes, and Gitlab has an update hook as well. My original theory was that this was happening because Git checks if it's a fast-forward before running hooks, and that the hooks taking a few seconds creates more opportunity for a race condition to occur.

However, after reading http://git.661346.n2.nabble.com/push-race-td7569254.html and doing some of my own testing (creating a hook that runs for 60 seconds and pushing from two locations to a test repo) this theory seems to be wrong. With the 60 second sleep hook (tried as an update hook and a pre-receive hook), I wasn't able to reproduce the problem. The second pusher always got an error like this:

error: Ref refs/heads/master is at 4584c1f34e07cea2df6abc8e0d407fe016017130 but expected 61b79b6d35b066d054fb3deab550f1c51598cf5f remote: error: failed to lock refs/heads/master

Which looks like exactly what I'd want Git to be doing in this scenario, and supports what that archived thread says about how this should work.

So the question is, how might this be happening and what can I do about it?

Thanks, Scott

Next: Matthieu Moy
Message 1 of 17 in “Git push race condition?”
  1. Scott SandlerMar 24, 2014
  2. Matthieu MoyMar 24, 2014
  3. Scott SandlerMar 24, 2014
  4. Matthieu MoyMar 24, 2014
  5. Junio C HamanoMar 24, 2014
  6. Ævar Arnfjörð BjarmasonMar 24, 2014
  7. Scott SandlerMar 24, 2014
  8. Jeff KingMar 24, 2014
  9. Jeff KingMar 24, 2014
  10. Nasser GrainawiMar 24, 2014
  11. Scott SandlerMar 25, 2014
  12. Matthieu MoyMar 25, 2014
  13. Scott SandlerMar 25, 2014
  14. Matthieu MoyMar 25, 2014
  15. Jeff KingMar 25, 2014
  16. Scott SandlerApr 10, 2014
  17. Matthieu MoyApr 11, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.