Git 远程：致命：将oh my zsh repo推送到新远程时，打包对象中出现fsck错误

我已经安装了

oh my zsh

，并做了一些本地更改，我想在

gitlab.com

上推送到另一个

git-remote

从GitLab文档中，我尝试了以下方法：

git push --set-upstream git@gitlab.com:alexzeitler/oh-my-zsh-modified.git

我得到这个错误：

Counting objects: 21586, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (8505/8505), done.
Writing objects: 100% (21586/21586), 4.23 MiB | 1.46 MiB/s, done.
Total 21586 (delta 12506), reused 20790 (delta 11901)
remote: error: object 2b7227859263b6aabcc28355b0b994995b7148b6: zeroPaddedFilemode: contains zero-padded file modes
remote: fatal: fsck error in packed object
error: unpack failed: index-pack abnormal exit
To gitlab.com:alexzeitler/oh-my-zsh-modified.git
 ! [remote rejected]   master -> master (unpacker error)
error: failed to push some refs to 'git@gitlab.com:alexzeitler/oh-my-zsh-modified.git'

我怎样才能解决这个错误？

为什么它会出现在你面前，我不知道

这里的问题是

https://github.com/robbyrussell/oh-my-zsh

本身（有些）损坏。这与你做的事无关。同时，您的

gitlab.com

服务被配置为非常严格。这也可能与您所做的任何事情都无关，但您需要更改它，或者放弃将此存储库发送到

gitlab.com

的想法。（或者，也许是你最好的选择，让他们注意到他们的修复程序本身是未修复的。）

如果您克隆上面的URL并在自己的克隆上运行

git fsck

，您将看到：

$ git fsck
Checking object directories: 100% (256/256), done.
warning in tree 2b7227859263b6aabcc28355b0b994995b7148b6: zeroPaddedFilemode: contains zero-padded file modes
warning in tree a18c4d13c2a5fa2d4ecd5346c50e119b999b807d: zeroPaddedFilemode: contains zero-padded file modes
warning in tree 84df066176c8da3fd59b13731a86d90f4f1e5c9d: zeroPaddedFilemode: contains zero-padded file modes
Checking objects: 100% (21666/21666), done.

Git当然是正确的：1

所有读取

040000

的条目都应读取

40000

。Git的内部对象格式要求

模式

条目的左边不能填零

这意味着无论是什么创建了这个存储库，都会创建一个违反规则的存储库。但是，正如您从我自己的

git fsck

输出中所看到的，这个特定的违反规则会从

git fsck

中得到警告，而不是直接的错误

无论何时设置Git服务器，例如，通过创建

gitlab.com

并将其出售给用户，您都可以选择如何控制所创建的新存储库中的

Git config

变量。这取决于您，或者在本例中，他们是控制

gitlab.com

的人。不管他们是谁，他们已经将控制旋钮设置为比默认值更严格。（另见。）

这是关于：

如果设置为true，git receive pack将检查所有接收到的对象。查看

transfer.fsckObjects

，了解检查的内容。默认为false。如果未设置，则使用

transfer.fsckObjects

的值

同时，部分内容如下：

未设置

fetch.fsckObjects

或

receive.fsckObjects

时，将使用此变量的值。默认为false

设置后，如果存在格式错误的对象或指向不存在对象的链接，则提取或接收将中止。此外，还检查了各种其他问题，包括遗留问题（请参阅

fsck.

），以及潜在的安全问题，如存在

.GIT

目录或恶意

.gitmodules

文件（有关详细信息，请参阅v2.2.1和v2.17.1的发行说明）。在将来的版本中可能会添加其他健全性和安全性检查

在接收端，失败的fsckObjects将使这些对象无法访问，请参阅中的“隔离环境”。在获取端，格式错误的对象将被保留在存储库中不被引用

如果您可以禁用

receive.fsckObjects

（和/或如果设置了

transfer.fsckObjects

，但我链接的GitLab通知建议它们只是始终设置

receive.fsckObjects

），您就可以打开自己的潜在漏洞2，从而将这个格式错误的存储库向前推。或者，如果可以设置

receive.fsck.skipList

，则可以列出这三个特定的格式错误的

树

对象，以便GitLab在声明这三个树是无害的同时，可以继续查找潜在的漏洞。或者，如果可以设置

fsck.zeroPaddedFilemode ignore

或

receive.fsck.zeroPaddedFilemode ignore

，也可以解决问题

是否可以以及如何设置这些，我不知道：如果您可以直接登录到

gitlab.com

，您可以

cd

到您自己的存储库并运行

git config

，但显然您不能。最后一个选择是说服所有使用robbyrussel存储库的人用一个新的正确的存储库来修复他们的存储库。然而，这对其他所有人来说都是痛苦的

---

1此处的演示是可疑的：

git cat file-p

规范化了树输出，因此这并没有真正显示问题所在

git cat file tree

获取原始数据，但树中充满了二进制数据（长度可变！），因此很难观察到

2此处的实际风险相当低：易受攻击的是Git的旧版本，而不是GitLab上的版本。GitLab在这里所做的是说，实际上，我们只存储最高质量的存储库，而不是那些包含我们所知道的可能存在的不可靠内容的存储库，以便在克隆存储库时闯入您的计算机。如果您运行的是最新版本的Git，那么您大概也不会受到攻击，因此GitLab向您提供的保护是您已经拥有的。但是，如果您运行的是旧的不可靠版本的Git，您可以购买GitLab的保护，而不是更新旧的不可靠Git

$ git cat-file -p 2b7227859263b6aabcc28355b0b994995b7148b6
100644 blob f84db6dc27af34f9f8e393f39a8aedf04ef86c0d    .gitignore
100644 blob 950f8861bc7ecbc25cd3544bf33e71cfb04a1ae7    README.textile
040000 tree 30b4ef0a0656cc9e2cfd4140a794bc018ab9e7d0    custom
040000 tree 4a22e953b9b4c774b13f78e157cb2f2b994e7b82    functions
040000 tree 56dccf6298605f85fc44025a0135e2dd796c1be9    lib
040000 tree 44f5974bb55c300d23cd39e96b1f7df57c4f9457    log
100644 blob eadf02d00fb0b625f58bd4ef2ea8dd56bcc85aef    oh-my-zsh.sh
040000 tree 5ffecc5c15dc9c3458de787e93135da481094717    templates
040000 tree 8a2c7f00e3c74ed417ce7458942b90ba56f4aeed    themes
040000 tree d6621bc3b6b3f5d6f70b119bade00a7d39494695    tools