Hi, On Thu, May 22, 2025 at 07:53:58PM +0300, david asraf wrote: > Thank you for filling out a Git bug report! > > Please answer the following questions to help us understand your issue. > > What did you do before the bug happened? (Steps to reproduce your issue) > > We have a system that runs many git commands on a local repo connected > to a remote repo on GitHub via HTTPS. Our system creates many commits > and works with many un-staged files. Every once in a while, we run the > following sequence of commands: > > git stash --all > > git checkout b1 > > git remote -v > > git fetch > > git status --branch --porcelain=v1 -u > > git checkout b2 > > git stash pop > > We start this sequence from branch b1 and record the output for internal use. > > What did you expect to happen? (Expected behavior) > > We expected git checkout b2 to succeed consistently. > > What happened instead? (Actual behavior) > > git checkout b2 sometimes fails because the HEAD.lock file already exists. > > What's different between what you expected and what actually happened? > > The git checkout b2 command, which previously succeeded consistently, > now occasionally fails due to the presence of a HEAD.lock file. This > issue started occurring after upgrading Git from version 2.39.5 to > 2.47.2. > > Anything else you want to add: > > Using GIT_TRACE_PERFORMANCE, we noticed that a Git maintenance process > (/usr/libexec/git-core/git maintenance run --auto --no-quiet --detach) > sometimes starts after the git fetch command, occasionally in detached > mode. We suspect this operation is causing the issue because we've > verified that the git maintenance command requires HEAD.lock before it > starts running. We are considering setting maintenance.autoDetach to > false. We are unsure if this is a bug or if it is working as intended, > and would appreciate your comments on this. thanks for your report! A couple months ago there was a similar discussion with someone else, but I cannot find that thread anymore, unfortunately. The root cause here is repository maintenance with `--auto --detach` will detach before spawning git-gc(1). This command may decide to pack your references and thus cause them to be locked. This then triggers a race condition, where the next Git command that wants to modify refs may not be able to lock "packed-refs" because we are still busy repacking them. The actual timeout to lock the "packed-refs" file is configurable via "core.packedRefsTimeout", so bumping this value may make the problem less likely to happen. But it's only papering over the actual issue. I'll send a patch series soonish that fixes this issue. I think the solution would be to make git-maintenance(1) learn about tasks that should run previous and after daemonizing the process to avoid this race condition. The effect would be that the caller of auto-maintenance will not continue before refs have been packed, which is similar to what git-gc(1) used to do in the past. Patrick
