Git返回“无法运行重新打包"和“膨胀返回"错误 [英] Git returns 'failed to run repack' and 'inflate returned' errors

问题描述

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

I am facing a problem with a Git repository stored on GitLab. It seems to be a repository issue only affecting this specific repository, as all other projects hosted on GitLab are working fine.

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

It seems I can personally push, pull, and checkout branches using GitKraken, but when I try to pull from Git Bash I get the following:

$ 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

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

All people cooperating with me on this same project have similar issues when attempting to pull:

$ 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

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

And this is what we all get when trying to clone the repository on a new location:

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

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

These are the things we tried:

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

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

I suspect, reading similar questions such as this one, that our repository is broken. However, I don't understand why I seem to be able to work with it via GitKraken. With its GUI, I successfully merged two branches and pushed the latest commits to the server.

有人对可能是什么问题有解释吗?

Does anybody have an explanation of what could be the problem?

尝试修复存​​储库

按照这些说明，该链接包含在我发布的链接中，同时也得到了下面的答案的建议，我运行了命令 git fsck --full 来检查存储库链接的状态.我发现并不能令人放心，因为似乎许多链接已断开.

Following these instructions contained in the link I posted, and also suggested by an answer below, I ran the command git fsck --full to examine the state of the repository links. What I found is not reassuring, as it seems many links are broken.

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 实例:

followed by a long list of dangling commit and dangling blob lines with 8 instances of missing ones:

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

似乎手动恢复损坏的文件将需要一些时间.

It seems like a manual recovery of the broken files would take quite some time.

编辑#2:本地固定存储库

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

I installed and ran git-repair in my local copy of the repository, and actually got it fixed. If I now run git fsck --full I only see "healthy" messages in response. No more broken links.

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

However, no matter if I git push --force to origin, it seems origin remains broken. One weird update is that now I can use git clone successfully, while all my co-workers still cannot. How can it be?

最重要的是，有没有一种方法可以真正在 origin 上运行 git-repair ?

And most importantly, is there a way I can actually run git-repair on origin?

编辑#3:新起源

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

After fixing my repository locally (and checked that git fsck gives no missing links) I pushed all relevant branches to a fresh origin on GitLab. I thought that was going to be it, but unfortunately the problem persists.

我开始注意到的一种模式是，我们似乎都可以从Ubuntu(使用Git Bash或GitKraken)进行克隆 clone ，但不能在Windows 10上(都不使用Git Bash或GitKraken)进行 clone .

A pattern I start to notice is that we seem to all be able to clone from Ubuntu (either using Git Bash or GitKraken) but not on Windows 10 (neither using Git Bash nor GitKraken).

仔细阅读网站，我发现一个问题，关于Git怎么可能在Linux上工作而不在Windows上工作.在那里，他们解释说这是一个与Git相关的问题(但已经有一年多了).发生类似的事情有意义吗?我不得不说对此持怀疑态度，因为我们测试过的其他存储库在Windows上都可以正常工作.

Reading around the website I found a question about how could it be possible that Git worked on Linux but not on Windows. There they explained it was a Git-related issue (but it was more than 1 year ago). Would it make sense something similar has happened? I have to say I'm skeptical about it, because other repositories we tested with work fine on Windows.

编辑#4:已在Windows的较旧版本的Git上进行了测试

当前版本为2.19.我在2.18和2.9(后一个日期为2016)上进行了尝试，但遇到了相同的错误.

Current version is 2.19. I tried it on 2.18 and 2.9 (the latter dating 2016) but I get the same error.

编辑#5:尝试成功在本地克隆

在关于 GitHub问题我在 git-for-windows 上写过，我试图从USB记忆棒上的存储库副本中使用 git clone .有效.该问题似乎仅限于Git + Windows + GitLab或Git + Windows + SSH.

After a suggestion on a GitHub issue I wrote on git-for-windows, I tried to use git clone from a copy of the repository on a USB stick. It worked. The problem seems to be confined to either Git+Windows+GitLab or Git+Windows+SSH.

推荐答案

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

As the linked answer points out, most of the objects in the tree are diffed and compressed to save bandwidth and disk, creating the mentioned .pack files.

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

During the pull process, the git client exchanges with the remote a list of refs and heads, so the remote can walk them and compute what objects need to be sent based on what the client already has. It then creates the packs And sends them to the client. This means that a pack sent to a client could be different from another for the same object.

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

As for why, I couldn't tell, but it's plausible that your repo is skipping the conflicting object, although since different clients throw this error in the same working copy this seems unlikely and looks like it might be just a software issue, maybe differences in the zlib used by each client.

您可以尝试 force-push 您的存储库(不推荐)，或者作为最后的选择推到其他遥控器.

You could try to force-push your repo (not recommended) or pushing to other remote as a last resort.

此外，从您链接的答案中，有一个过程可以尝试和修复损坏的存储库.

Also, from the answer you link, there's a procedure to try and fix broken repositories.

更新:作为后续， -5 是zlib上的 Z_BUF_ERROR ，并根据

UPDATE: As a followup, -5 is Z_BUF_ERROR on zlib and according to the documentation:

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

inflate() returns Z_OK if some progress has been made [...] Z_BUF_ERROR if no progress was possible or if there was not enough room in the output buffer when Z_FINISH is used. Note that Z_BUF_ERROR is not fatal, and inflate() can be called again with more input and more output space to continue decompressing. If Z_DATA_ERROR is returned[...]

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

I personally think the bug is in the software, rather than in GitLab, but that's speculation on my part.

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

And a suggestion: If it's not possible to move all devs to Linux... What about the Linux subsystem for W10 ?

这篇关于Git返回“无法运行重新打包"和“膨胀返回"错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！