Re: Races on ref .lock files?

Andreas Krey [off-list ref] writes:

In a different instance, we have a simple bare git repo that we
use for backup purposes. Which means there are lots of pushes
going there (all to disjunct refs), and I now cared to look
into those logfiles:

----snip
Wed Dec 21 05:08:14 CET 2016
fatal: Unable to create '/data/git-backup/backup.git/packed-refs.lock': File exists.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.
error: failed to run pack-refs
To git-backup-user@socrepo.advantest.com:backup.git
 + 8aac9ae...2df6d56 refs/zz/current -> refs/backup/socvm217/ZworkspacesZsocvm217ZjohanabtZws-release_tools.Ycurr (forced update)
----snip

I interpret this as "I updated the refs files, but packing them
didn't work because someone else was also packing right now."

Correct.

Is that happening as designed, or do I need to be afraid
that some refs didn't make the push?

Correct and No.  Packing refs into the packed-refs file is merely a
performance thing and done under the lock (needless to say, updating
individual refs is also done under the lock).  Your push may have
competed with somebody else's push that started earlier and you may
have given up packing refs, but no ill effect should be left behind.

When the lock holder (the other guy who competes with your push)
stuffs refs into a packed-refs file, the values for the refs you
pushed may not be in the packed-refs file, because the other guy may
have observed and captured the value before your push updated them.
Those refs updated by you that are missed by the other guy will be
left as loose refs.  Because whenever Git tries to find the value
for a ref, it always checks the loose refs first, there is no issue
due to this.