Running version 1.9.4.msysgit.0 of git, I'm getting the mentioned error(s) almost every time I run git gc on the command-line or via git gui when it prompts me to "compress loose objects":
Counting objects: 1110956, done. Delta compression using up to 4 threads. Compressing objects: 100% (269562/269562), done. Writing objects: 100% (1110956/1110956), done. Total 1110956 (delta 636114), reused 1110956 (delta 636114) Unlink of file '.git/objects/pack/pack-207f1feb5376880778637c ... 8371cea62.pack' failed. Should I try again? (y/n) n Checking connectivity: 1110956, done. The only solution seems to be hitting n for each of the locked files - as suggested by this thread:
Short answer: hit 'n' to get through all of those, and then manually run "git gc".
The thread also suggests that...
The problem is that the files are held open by a parent git.exe of the one that's trying to do the gc.
...which, when looking at the process tree, is entirely plausible:
My question is, is there something I can do to prevent this? It's getting really annoying having to do this multiple times a day... And why does it happen? Is it a git/w32-only bug?
Update 1: To clarify - after hitting n several times as described, git gc finishes and the local repository is "clean", i.e. re-running git gc will not cause said file lock problems anymore - but this is only for some timegit gc from within git-bash instead of cmd as suggested by jsexpert does not help. He further suggested that other non-gitgit
Update 2: Turns out that jsexpert was right all along - at least in my case it was indeed the IDE locking on those files... So it's an issue of the EGit Team Provider for Eclipse, and not git itself.
Update 3: To find locked files, you can for example use one of these free tools:
- Process Explorer (by now, a Microsoft offering)
- Process Hacker (by now, replaced Process Explorer in my toolset)
In both of these, use CTRLF to bring up the "Find Handle" dialog.