0

Oftenly when I do a git pull --rebase I get this kind of output:

> git pull --rebase
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
Enumerating objects: 249988, done.
Counting objects: 100% (249988/249988), done.
Delta compression using up to 12 threads.
Compressing objects: 100% (62830/62830), done.
Writing objects: 100% (249988/249988), done.
Total 249988 (delta 179539), reused 249988 (delta 179539)
Unlink of file '.git/objects/pack/pack-00a0089ffcdc3d5ea5d2cc81042b741ba6d55a7d.idx' failed. Should I try again? (y/n)

The question is repeated a hundred or so times for each file that is suppossedly locked.

The referred file can be anything random-ish, but it is always a file in the .git/objects/pack/ directory. As far as I can tell, there's no other software keeping those files locked.

It seems like this problem occurs mostly after switching branches.

I'm using Git 2.18 on Windows 10.

I prefer not to dive into WLS or git-bash. While that would be a workaround to get the rebase to work, I do eventually want to get rid of this problem on the regular command prompt.

Another workaround is to execute git gc first. That command is somehow able to release these files and make subsequent commands work as expected.

This question seems like a duplicate of my question, but speaks of a fix in Git 2.8 (which we are pretty far beyond by now) and the poster uses git-bash, which is a different scenario anyway.

Martijn
  • 13
  • 1
  • 5
  • `I'm using Git 2.18 on Windows 10.` had same issue yesterday, system reboot fixed the issue in my case. – Marek R Mar 22 '19 at 12:02

1 Answers1

0

This message means that some other process on your system is using those files. It's possible that you have an editor plugin or other software that uses Git or libgit2 to access those files, and Windows doesn't allow them to be removed while they're in use. This is a limitation of Windows and the Win32 API which doesn't apply to Unix systems or WSL.

You can close or kill the other process, reboot, or switch to using WSL, which will allow removing files that are in use.

bk2204
  • 64,793
  • 6
  • 84
  • 100
  • Like I said, nothing is using those files, as far as I can tell. – Martijn Mar 25 '19 at 09:39
  • It may appear that that's the case, but the error message almost always means that something is using it. If you look at other people who have had the same problem, finding and fixing the program keeping the file open is the key to making it work. – bk2204 Mar 25 '19 at 20:25