我已安装oh-my-zsh并进行了一些本地更改，我想将其推送到git remote上的另一个gitlab.com。
在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'
如何解决此错误？
答案 0 :(得分：1)
In theory, this was already fixed at GitLab.为什么要为您显示，我不知道。
这里的问题是https://github.com/robbyrussell/oh-my-zsh本身已经（有点）损坏了。这与您所做的任何事情都不相关。同时，您的gitlab.com服务被配置为超严格。此 可能与您所做的任何操作无关，但是您需要对其进行更改，否则放弃发送此的想法em>存放到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
$ 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
所有读取040000的条目都应读取40000。 Git的内部对象格式要求mode项 not 的左侧为零。
的意思是，无论创建该存储库如何，都创建了违反规则的存储库。但是，正如您从我自己的git fsck输出中看到的那样，这种特殊的违反规则会从git fsck中引出警告，而不是完全的错误。
无论何时设置Git服务器（例如，通过创建gitlab.com并将其出售给用户），您都可以选择如何控制所创建的新存储库中的git config变量。这取决于您，或者在这种情况下，他们是控制gitlab.com的人—才能做到这一点。无论他们是谁，他们都将控制旋钮设置为比默认值严格。 （另请参见this 2014 notice。）
The git config documentation谈到receive.fsckObjects：
如果将其设置为true，则git-receive-pack将检查所有接收到的对象。有关检查内容，请参见
transfer.fsckObjects。默认为false。如果未设置，则使用transfer.fsckObjects的值。
与此同时，the transfer.fsckObjects section部分读取：
未设置
fetch.fsckObjects或receive.fsckObjects时，将使用此变量的值。默认为false。设置该选项后，如果对象格式错误或指向不存在的对象的链接，则提取或接收将中止。此外，还会检查其他各种问题，包括遗留问题（请参阅
fsck.<msg-id>）和潜在的安全问题，例如存在.GIT目录或恶意的.gitmodules文件（请参阅发行版）有关v2.2.1和v2.17.1的详细信息，请参见注释）。其他健全性和安全性检查可能会在将来的版本中添加。在接收方，失败的fsckObjects将使这些对象无法访问，请参阅git-receive-pack[1]中的“ QUARANTINE ENVIRONMENT”。在获取方面，格式错误的对象将改为在存储库中未被引用。
如果您可以禁用receive.fsckObjects（和/或已设置transfer.fsckObjects，但我链接的GitLab通知建议它们仅设置receive.fsckObjects），则可以打开潜在的漏洞 2 ，因此将这个格式错误的存储库向前推。或者，如果您可以设置receive.fsck.skipList，则可以列出这三个特定的格式错误的tree对象，以便GitLab在声明这三棵树无害的同时可以继续寻找潜在的漏洞。或者，如果您可以设置fsck.zeroPaddedFilemode ignore或receive.fsck.zeroPaddedFilemode ignore，那也可以解决问题。
是否以及如何设置这些设置，我都不知道：如果您可以直接登录gitlab.com，则可以cd登录到自己的存储库并运行git config，但是显然您可以不能。您最后的选择是说服所有使用robbyrussel信息库的人使用新的更正后的信息库来修复其信息库。但是，这对其他所有人来说都是痛苦的。
1 这里的演示是可疑的：git cat-file -p规范化了树的输出，因此这并没有真正显示出问题。 git cat-file tree <hash>获取原始数据，但是树上充满了二进制数据（长度可变！），因此很难观察。
2 这里的实际风险非常低：容易受到攻击的是Git的旧版本，而不是GitLab本身的版本。 GitLab在这里所做的实际上是说，我们只存储最高质量的存储库，而不存储那些据我们所知可能存在的，目的是为了闯入您的
克隆存储库时，可以使用强壮的计算机。如果您运行的是最新版本的Git，那么您可能也不容易受到攻击，因此GitLab在这里卖给您的保护无论如何都是您已经拥有的。但是，如果您运行的是老版本的Git，则可以购买GitLab的保护，而不必更新您的老版本的Git。