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, David. Please review the rest of the bug report below. You can delete any lines you don't wish to share. [System Info] git version: 2.47.2
