6

从一个拉到下一个，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目录复制到旧文件夹中？或者有没有其他解决方案而不接触目录？

4

3 回答 3

1

我可以通过

  1. 尝试获取（有错误）
  2. 像上面一样复制目标文件
  3. git merge提交丢失的目标文件。

现在似乎解决了，错误不再出现。

于 2013-03-24T10:09:24.660 回答
1

我正在运行一个开发团队，它有一个损坏的 git 存储库，因为我们还没有时间修复它。我发现有很多东西可以让球保持移动，这可能会有所帮助。

首先有一台 [gc] auto=0 的机器并将整个 repo 解压到对象

其次 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... 将在 objects/0c/ 0ef24...)

对我来说，为什么 git fetch/pull 没有意识到这些从本地 git 中丢失并从原点获取它们对我来说是一个谜，但似乎手动执行 fetch 会使 git 再次快乐。一旦你手动修复了一个 git repo 运行 git gc （但不是在解压的机器上，否则你需要找到丢失的对象才能再次手动修复，这很烦人）

真正方便的是一个命令告诉 git 从原点获取特定对象，但我想如果它不需要被问到就更好了:-)

希望有帮助。

于 2013-04-22T13:46:17.073 回答
0

我今天在尝试使用 git 1.7.1 从 centos 6 盒子中 git pull 时遇到了这个问题。在我将 git 客户端从 rpmforge-extras 升级到 1.7.11 后，问题就解决了。

于 2013-05-30T08:32:34.917 回答