Re: HEAD.lock and git maintenance

[Patrick Steinhardt <ps@pks.im>]

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