Andreas Krey <a.krey@xxxxxx> writes: > We're occasionally seeing a lot of > > error: cannot lock ref 'stash-refs/pull-requests/18978/to': Unable to create '/opt/apps/..../repositories/68/stash-refs/pull-requests/18978/to.lock': File exists. > > from the server side with fetches as well as pushes. (Bitbucket server.) > > What I find strange is that neither the fetches nor the pushes even > touch these refs (but the bitbucket triggers underneath might). > > But my question is whether there are race conditions that can cause > such messages in regular operation - they continue with 'If no other git > process is currently running, this probably means a git process crashed > in this repository earlier.' which indicates some level of anticipation. I think (and I think you also think) these messages come from the Bitbucket side, not your "git push" (or "git fetch"). Not having seen Bitbucket's sources, I can only guess, but assuming that its pull-request is triggered from their Web frontend like GitHub's does, it is quite possible when you try to "push" into (or "fetch" from, for that matter) a repository, somebody is clicking a button to create that ref. We do not know what their "receive-pack" that responds to your "git push" (or "upload-pack" for "git fetch") does when there are locked refs. I'd naively think that unless you are pushing to that ref you showed an error message for, the receiving end shouldn't care if the ref is being written by somebody else, but who knows ;-) They may have their own reasons wanting to lock that ref that we think would be irrelevant for the operation, causing errors.