title: git gc / git gui: Unlink of file <internal pack file name> failed
body: <p>Running version <code>1.9.4.msysgit.0</code> of <code>git</code>, I'm getting the mentioned error(s) almost every time I run <code>git gc</code> on the command-line or via <code>git gui</code> when it prompts me to "compress loose objects":</p>
  
  <pre><code>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.
  </code></pre>
  
  <p>The only solution seems to be hitting <kbd>n</kbd> for each of the locked files - as suggested by <a href="https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/IsZHwxz2Jeg" rel="noreferrer">this thread</a>:</p>
  
  <blockquote>
    <p>Short answer: hit 'n' to get through all of those, and then manually
    run "git gc". </p>
  </blockquote>
  
  <p>The thread also suggests that...</p>
  
  <blockquote>
    <p>The problem is that the files are held open by a parent git.exe of the one that's trying to do the gc.</p>
  </blockquote>
  
  <p>...which, when looking at the process tree, is entirely plausible:</p>
  
  <p><img src="https://i.stack.imgur.com/eYPT6.jpg" alt="git process tree"></p>
  
  <p>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?</p>
  
  <hr>
  
  <p><strong>Update 1:</strong> To clarify - after hitting <kbd>n</kbd> several times as described, <code>git gc</code> finishes and the local repository is "clean", i.e. re-running <code>git gc</code> will not cause said file lock problems anymore - <em>but this is only for some time</em>. After working sometime on the repo &ndash; sometimes after minutes, sometimes after hours &ndash; the repository is "dirty" again and the described problems prevail. Running <code>git gc</code> from within <code>git-bash</code> instead of <code>cmd</code> as suggested by <a href="https://stackoverflow.com/users/1755598/codewizard">CodeWizard</a> does not help. He further suggested that other non-<code>git</code> software might be holding the locks in question. I am skeptical of that, not least due to the comment in thread linked above &ndash; I think a parent <code>git</code> process is holding the locks &ndash; but I still have to verify that claim.</p>
  
  <p><strong>Update 2:</strong> Turns out that <a href="https://stackoverflow.com/users/1755598/codewizard">CodeWizard</a> 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 <a href="http://eclipse.org/egit/" rel="noreferrer">EGit Team Provider</a> for Eclipse, and not <code>git</code> itself.</p>
  
  <p><img src="https://i.stack.imgur.com/Z67RD.jpg" alt="enter image description here"></p>
  
  <p><strong>Update 3:</strong> To find locked files, you can for example use one of these free tools:</p>
  
  <ul>
  <li><a href="https://technet.microsoft.com/de-de/sysinternals/bb896653.aspx" rel="noreferrer">Process Explorer</a> (by now, a Microsoft offering)</li>
  <li><a href="http://processhacker.sourceforge.net/" rel="noreferrer">Process Hacker</a> (by now, replaced Process Explorer in my toolset)</li>
  </ul>
  
  <p>In both of these, use <kbd>CTRL</kbd><kbd>F</kbd> to bring up the "Find Handle" dialog.</p>