Question

在我的回购邮件上运行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.

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

Answer 1

它不会轻易地打破 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可以修复它（通过重放提交来获取“正确的”树对象），但是您必须弄清楚哪个分支包含包含这些树的提交，并且还必须清除“坏”提交引用坏树对象。（当然，这会给任何克隆回购邮件的人带来各种痛苦。）（2）这是如何产生的？

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

我应该担心`git fsck`警告：“包含零填充文件模式”

1 个答案: