git - Git返回“无法运行重新打包”和“膨胀返回”错误

我在GitLab上存储的Git存储库遇到了问题。这似乎只是一个存储库问题，仅影响此特定存储库，因为在GitLab上托管的所有其他项目都运行良好。

似乎我可以使用GitKraken亲自推送，拉出和检出分支，但是当我尝试从Git Bash中拉出时，会得到以下信息：

$ git pull
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
error: Could not read bb5a805503a3da247038200df7002f452a8781e9
fatal: bad tree object bb5a805503a3da247038200df7002f452a8781e9
error: failed to run repack

在同一项目上与我合作的所有人在尝试拉动时都遇到类似的问题：

$ git pull
remote: Enumerating objects: 112, done.
remote: Counting objects: 100% (112/112), done.
remote: Compressing objects: 100% (102/102), done.
fatal: pack has bad object at offset 8105548: inflate returned -5
fatal: index-pack failed

这就是我们在新位置上克隆存储库时得到的一切：

remote: Enumerating objects: 4364, done.
remote: Counting objects: 100% (4364/4364), done.
remote: Compressing objects: 100% (1622/1622), done.
fatal: pack has bad object at offset 56589977: inflate returned -5
fatal: index-pack failed

这些是我们尝试过的事情：

测试了多台计算机
测试了多个用户

我怀疑，在阅读类似this one之类的问题时，我们的存储库已损坏。但是，我不明白为什么我似乎可以通过GitKraken使用它。通过其GUI，我成功地合并了两个分支并将最新的提交推送到服务器。

有人对可能的问题有解释吗？

编辑：尝试修复存储库

在我发布的链接中包含these instructions之后，并且在下面的回答中也提出了建议，我运行了git fsck --full命令来检查存储库链接的状态。我发现并不能令人放心，因为似乎许多链接已断开。

Checking object directories: 100% (256/256), done.
Checking objects: 100% (3769/3769), done.
broken link from  commit f42ccacb8101ef49493aca18089378697490bb66
              to    tree e461e3cbe3221cd5ba7035222aa716dcabb63713
broken link from  commit 2fe8ac2b06d8e8f37b354c395f60a77f0ab1f9a9
              to    tree 93b9618cc159c1b18aba319e8f7e3e5e8f7b57df
broken link from  commit 16d23305969b3a40316618b952b2e5ff1ffedbf6
              to    tree 80c4012d9f3b3f51f17932dec80e740bc4e5a1d6
broken link from    tree 867941d734b41a5ce800dff6ea7dbfca30787e15
              to    tree bb5a805503a3da247038200df7002f452a8781e9
broken link from    tree e16211709ea4ce02a89bbe87d30a410dac65e372
              to    blob b6eb83a9e4f16fe49a0eb9bfea0bf6dfce9adcbc
broken link from    tree e16211709ea4ce02a89bbe87d30a410dac65e372
              to    blob a593c8f43faacf41bc93c98dbb347e673cd47f3f
broken link from    tree e16211709ea4ce02a89bbe87d30a410dac65e372
              to    blob 652245900beb49246e58f5c216dbcf161f727e2d
broken link from    tree e16211709ea4ce02a89bbe87d30a410dac65e372
              to    blob a7998441f7435126feb6b35e9b4b575bd193d6d2

后跟一长串dangling commit和dangling blob行，以及8个missing实例：

[...]
missing tree 80c4012d9f3b3f51f17932dec80e740bc4e5a1d6
[...]
missing blob a593c8f43faacf41bc93c98dbb347e673cd47f3f
[...]
[6 more]

似乎手动恢复损坏的文件将需要相当长的时间。

编辑＃2：本地固定存储库

我在存储库的本地副本中安装并运行了git-repair，实际上已将其修复。如果现在运行git fsck --full，我只会看到“健康”消息。不再有断开的链接。

但是，无论我是否git push --force到origin，似乎origin仍然坏了。一个奇怪的更新是，现在我可以成功使用git clone，而我的所有同事仍然不能使用。怎么可能？

最重要的是，有没有一种方法可以使我在git-repair上实际运行origin？

编辑＃3：新起源

在本地修复了存储库（并检查git fsck没有丢失的链接）后，我将所有相关分支推到了GitLab上的新位置。我以为就是这样，但是不幸的是问题仍然存在。

我开始注意到的一种模式是，我们似乎都可以从Ubuntu（使用Git Bash或GitKraken）clone进行操作，但是在Windows 10上（既不使用Git Bash也不使用GitKraken）都可以{

在网站上阅读后，我发现a question关于Git如何在Linux上而不是Windows上工作。在那里，他们解释说这是一个与Git有关的问题（但已经有一年多了）。发生类似的事情有意义吗？我必须对此表示怀疑，因为我们测试过的其他存储库在Windows上都可以正常工作。

编辑＃4：已针对Windows的较旧版本的Git进行了测试

当前版本为2.19。我在2.18和2.9（后一个日期为2016）上进行了尝试，但出现了相同的错误。

编辑＃5：尝试成功在本地克隆

在对我在git-for-windows上写过的GitHub issue的建议之后，我尝试使用USB记忆棒上存储库副本中的git clone。有效。该问题似乎仅限于Git + Windows + GitLab或Git + Windows + SSH。

正如链接的答案所指出的，树中的大多数对象都经过扩散和压缩以节省带宽和磁盘，从而创建了提到的.pack文件。

在拉取过程中，git客户端与远程交换ref和head的列表，因此远程可以遍历它们并根据客户端已经拥有的内容计算需要发送的对象。然后，它创建包并将其发送给客户端。这意味着对于同一对象，发送给客户端的数据包可能与另一个不同。

至于为什么，我不知道，但这是合理的，因为您的存储库正在跳过冲突的对象，尽管由于不同的客户端在同一工作副本中抛出此错误，这似乎不太可能，并且看起来像可能只是软件问题，可能是每个客户端使用的zlib不同。

您可以尝试force-push进行回购（不推荐）或作为最后的选择推到其他遥控器。

此外，从您链接的答案中，有一个过程可以尝试和fix broken repositories。

更新：作为后续工作，-5在zlib上是Z_BUF_ERROR，并根据documentation：

如果已取得某些进展，
inflate（）返回Z_OK [...] Z_BUF_ERROR，如果没有进度或进度不足使用Z_FINISH时，输出缓冲区中的空间。请注意，Z_BUF_ERROR 不是致命的，可以使用更多输入再次调用inflate（），更多的输出空间可继续进行解压缩。如果Z_DATA_ERROR是返回[...]

我个人认为该错误是在软件中，而不是在GitLab中，但这是我的推测。

还有一个建议：如果不可能将所有开发人员都转移到Linux ... W10的Linux子系统呢？

Git返回“无法运行重新打包”和“膨胀返回”错误

1 个答案: