Andreas, Bitbucket Server developer here. Typically these errors on your client are indicative of git gc --auto being triggered by git-receive-pack on the server. Auto GC directly attached to a push in a repository with pull requests often fails due to concurrent ref updates linked to background pull request processing. If you'd like to investigate more in depth, I'd encourage you to create a ticket on support.atlassian.com so we can work with you. Otherwise, if you just want to prevent seeing these messages, you can either fork the relevant repository in Bitbucket Server (which disables auto GC), or run "git config gc.auto 0" in /opt/apps/.../repositories/68. Once auto GC is disabled, Bitbucket Server will automatically take over managing GC for the repository without any additional configuration required. Note that we're working on revamping our GC handling such that auto GC will always be disabled for all repositories and managed explicitly within Bitbucket Server instead, so a future upgrade should automatically prevent these messages from appearing on clients. Best regards, Bryan Turner On Fri, Dec 16, 2016 at 9:20 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. > > >