在命令行或通过git gui
运行git gc
时,使用1.9.4.msysgit.0
版本的git
,我几乎每次都会遇到下面提到的错误,提示我“压缩松散对象”:
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.
唯一的解决方法似乎是,按下每个被锁定文件的 n 键 - 正如这个帖子所建议的:
简短的回答:按 'n' 来通过所有这些,然后手动运行 "git gc"。
该线程还建议...
问题在于,这些文件被一个正在尝试进行垃圾回收操作的 git.exe 的父进程占用。
...当查看进程树时,这是完全可能的:
我的问题是,有没有什么我可以做来防止这种情况?每天多次这样做真的很烦人...而且为什么会发生?这是一个仅限于 git/w32 的 bug 吗?
更新1:澄清一下 - 按照描述多次按下 n 键后,git gc
完成,本地存储库已经 "干净",即重新运行 git gc
将不会再次导致所述文件锁定问题 - 但这只是一段时间。在存储库上工作一段时间后 - 有时是几分钟,有时是几个小时 - 存储库又变 "脏" 了,描述的问题仍然存在。像CodeWizard建议的那样,在git-bash
而不是在cmd
中运行git gc
并没有帮助。他进一步指出,可能是其他非 git 软件持有了相关的锁。我对此持怀疑态度,不仅因为链接上面的线程中的评论 - 我认为父 git
进程正在持有锁 - 但我仍然需要验证该说法。
更新2: 原来CodeWizard一直是正确的 - 至少在我的情况下确实是 IDE 锁定了那些文件...所以这是一个Eclipse 的 EGit Team Provider问题,而不是 git
本身的问题。
更新3: 您可以使用以下其中一种免费工具来查找锁定的文件:
- Process Explorer(现在是微软的产品)
- Process Hacker(现在已经取代 Process Explorer 成为我的工具集中的一员)
在这两个工具中,使用CTRLF来打开“查找句柄”对话框。