Unlink of *.idx file fails when running git pull

[Aerocatia]

Existing issues matching what you're seeing

• I was not able to find an open or closed issue matching what I'm seeing

Git for Windows version

git version 2.54.0.windows.1
cpu: x86_64
built from commit: 2b8a3ab140826ac423c2845ef81d4c6ac4f7bf3c
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
rust: disabled
feature: fsmonitor--daemon
gettext: enabled
libcurl: 8.19.0
OpenSSL: OpenSSL 3.5.6 7 Apr 2026
zlib: 1.3.2
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1

Windows version

Windows 10

Windows CPU architecture

x86_64 (64-bit)

Additional Windows version information

Microsoft Windows [Version 10.0.19044.7291]

Options set during installation

Editor Option: Nano
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Rebase
Use Credential Manager: Disabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Enabled
Enable FSMonitor: Disabled

Other interesting things

The drive (and git repos) have also been accessed by Windows 11. Most were created in that environment.

Terminal/shell

git for windows bash in the Windows Terminal

Commands that trigger the issue

git pull

Expected behaviour

clean pull of new commits

Actual behaviour

Common to see the following.

Unlink of file '.git/objects/pack/pack-<some hash>.idx' failed. Should I try again? (y/n)

Y never works. Nothing else other than git's bash instance is running, so nothing should have a lock on the files.

I have also seen this issue referenced here: ScoopInstaller/Scoop#6665

Repository

No response

[5891]

Is this...? Seems no release yet, though.

[rimrul]

Is this...?

That looks like the same issue indeed.

Seems no release yet, though.

There are snapshot builds, though.

@Aerocatia could you test the latest snapshot to see if it fixes your issue?

[5891]

git config --global maintenance.auto false
scoop reset git@2.54.0

then five times of scoop update (each time with changes), the error still had not reproduced for me. then true, it immediately reproduced on the first try (even without changes).

i hope this is not off-topic and pointless here...

[dscho]

i hope this is not off-topic and pointless here...

Given that Scoop is not supported by Git for Windows, and that there is this standing invitation to test a snapshot, I could think of something that would be a good use of your time ;-)

[Aerocatia]

I have been trying the latest snapshot, but the problem is this does not happen consistently on the release build so I can't say for sure if it's fixed or if the condition that triggers it is simply not happening.

I have even tried to force it with git reset --hard / git gc and re-pulling

[Juma-creator]

Thank you for reporting this issue. To help us investigate further, could you please provide:

• The exact steps you ran before encountering the unlink error
• Output of git fsck to check repository integrity
• Confirmation of your Git version (git --version) and operating system details
• Whether antivirus or indexing services are running that might lock .idx files
• Whether the issue persists in a freshly cloned repository
• If running git gc changes the behavior

Additionally, please let us know if the repository is being accessed from multiple Windows versions (e.g., Windows 10 and Windows 11), as this may affect file locking behavior.

Once we have this information, we’ll be able to determine whether this is a Git for Windows bug, an environment-specific issue, or related to external processes. If reproducible, we’ll escalate and track it as a confirmed bug.

[Juma-creator]

Unlink of file '.git/objects/pack/pack-.idx' failed. Should I try again? (y/n)

[AnthonySWest]

I am also getting this error when fetching, on Windows 10, after upgrading to 2.54.0.windows.1.

[dscho]

The solution is to switch to a snapshot for now. This close to v2.55.0-rc0 (it's just one week out), I do not want to tire Git for Windows users with an out-of-band release.