git gc / git gui: Unlink of file <internal pack file name> failed

Question

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 time. After working sometime on the repo – sometimes after minutes, sometimes after hours – the repository is "dirty" again and the described problems prevail. Running git gc from within git-bash instead of cmd as suggested by CodeWizard does not help. He further suggested that other non-git software might be holding the locks in question. I am skeptical of that, not least due to the comment in thread linked above – I think a parent git process is holding the locks – but I still have to verify that claim.

Update 2: Turns out that CodeWizard 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.

Answer 1

What I recommend you to do is to use git from the git-bash (i.e. %GIT_HOME%\bin\bash.exe) and not from cmd. Once switching to git-bash you should not expect to get this problem since cmd is a Windows command that might lock your files, while git-bash is like a UNIX emulator which will not lock your files (even if it's actually looking on your Windows folders).