On Mon, May 26, 2025 at 6:22 AM Patrick Steinhardt [off-list ref] wrote:

Hi,

On Thu, May 22, 2025 at 07:53:58PM +0300, david asraf wrote:

quoted

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.

Google had a big problem with this behavior about a year ago, I'm not
sure if we got far with a thread about it though. That may be what
you're thinking of.

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.

We'll look forward to this series with interest, thanks.

 - Emily

Patrick