8

在我的仓库上运行git fsck，我得到这个输出：

$ git fsck
Checking object directories: 100% (256/256), done.
warning in tree bde551ba2d6882ac7614c25305c24ddc1c75b1c4: contains zero-padded file modes
warning in tree 7cac28aefa67ff63e5ca163de382a3e08b8a7ba5: contains zero-padded file modes
warning in tree c24803abe783decd96c1dbf05d3ac45dbf3ff372: contains zero-padded file modes
warning in tree 51393697adb908ddb5fac540a86ea5a331fc1da5: contains zero-padded file modes
Checking objects: 100% (40275/40275), done.

我应该担心这些警告吗？他们会损坏我的回购吗？

4

1 回答 1

4

它不会彻底破坏repo，但它是可疑的。零填充文件模式的测试早在 2005 年就开始了：

commit 64071805eda2b57d2b77943bb3f9865d90562ecf
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date:   Wed Jul 27 16:08:43 2005 -0700

    git-fsck-cache: be stricter about "tree" objects

    In particular, warn about things like zero-padding of the mode bits,
    which is a big no-no, since it makes otherwise identical trees have
    different representations (and thus different SHA1 numbers).

    Also make the warnings more regular.

    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

不同的 SHA1 值将使 git 相信“树 A”与“树 B”不同，即使它们在所有重要方面都相同（相同的文件和模式，除了前导零），这将使回购略大于必要。此外，两个实际上相同的提交（例如，通过重放补丁创建）看起来是不同的。我不知道结果会出现什么问题，但它可能会混淆各种操作（他们“期望”找到差异，但随后找不到任何差异）并且随着时间的推移它可能会使存储库膨胀。

两个有趣的附加问题：（1）你如何解决这个问题？我怀疑使用git filter-branch可以修复它（通过重播提交以获得“正确”树对象），但您必须弄清楚哪些分支包含包含这些树的提交，并且还必须清除“坏”提交指坏树对象。（当然，这会给任何克隆 repo 的人带来各种痛苦。）（2）这首先是如何产生的？

看看git cat-file这些树的打印内容会很有趣，尽管git cat-file -p添加了前导零，所以这有点痛苦。（git cat-file tree bde551ba2d6882ac7614c25305c24ddc1c75b1c4转储原始内容，但它们充满了二进制位。仍然可以查看，只需要使用处理二进制内容的东西。）

于 2013-03-24T22:48:33.763 回答