从一个拉到下一个，服务器上的每个git pull都以此结束：
$ git pull
remote: Counting objects: 53, done.
remote: Compressing objects: 100% (32/32), done.
remote: Total 32 (delta 19), reused 0 (delta 0)
Unpacking objects: 100% (32/32), done.
error: unable to find 71682baccff823caa21420b16dd231c6b9c1b133
fatal: object 71682baccff823caa21420b16dd231c6b9c1b133 not found
与git fetch相同。我可以通过将文件.git/object/71/682baccff823caa21420b16dd231c6b9c1b133复制到服务器来解决这个问题，但经过多次拉动后，错误仍然存在，每次都有分支上的最新提交对象。
这怎么可能发生？我该如何解决这个问题？
完整的git clone不是一个好的解决方案，因为这个存储库位于正在运行的服务器项目上，并且有更多的文件没有git控件。
是否可以clone进入新目录，然后将.git目录复制到旧文件夹中？或者没有触及目录还有其他解决方案吗？
答案 0 :(得分：0)
我可以通过
解决问题git merge提交缺少的目标文件。现在似乎已经解决了，错误不再出现了。
答案 1 :(得分：0)
我正在运行一个开发团队，其中包含一个损坏的git存储库，因为我们还没时间修复它。我发现有很多东西让球保持运动，这可能会有所帮助。
首先让一台机器[gc] auto = 0并将整个仓库解包到对象
其次git 1.8似乎处理的问题比1.7好，所以有一台git 1.8的机器可以访问包含源代码的文件系统。
第三，总是从1.8机器git fetch，然后从1.7机器git pull
第四，即使1.8不能git pull，你需要运行git fsck | grep missing并手动将解压缩的repo中的对象复制到损坏的repo上的对象存储中（缺少0c0ef24 ...将在对象中） / 0C / 0ef24 ...）
对我来说这是一个谜，为什么git fetch / pull没有意识到这些都是从本地git中丢失并从原点获取它们，但似乎手动执行获取使得git再次开心。一旦你手动修复了一个git repo运行git gc（但没有在解压缩的机器上，或者你需要找到丢失的对象才能再次手动修复，这很烦人）
真正方便的是告诉git从原点获取特定对象的命令，但我想如果它不需要被问到它会更好： - ）
希望有所帮助。
答案 2 :(得分：0)
我今天遇到了这个问题，同时试图用git 1.7.1从一个centos 6盒子中拉出来。我将git客户端从rpmforge-extras升级到1.7.11后解决了这个问题。