Andreas Krey <a.krey@xxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx: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.