Should I worry about `git fsck` warning: "contains zero-padded file modes"

Question

Running git fsck on my repo, I get this output:

$ 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.

Should I be worried about these warnings? Can they damage my repo?

Answer 1

It won't exatly break the repo, but it's suspicious. The test for zero-padded file modes went in way back in 2005:

commit 64071805eda2b57d2b77943bb3f9865d90562ecf
Author: Linus Torvalds <[email protected]>
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 <[email protected]>

The different SHA1 values will make git believe that "tree A" is different from "tree B" even when they're the same in all important ways (same files and modes except for the leading zero(s) in one), which will make the repo slightly bigger than necessary. Moreover, two actually-identical commits (e.g., created by replaying a patch) would appear to be different. I don't know of anything that will go wrong as a result, but it could confuse various operations (they "expect" to find differences, but then don't find any) and over time it might bloat-up the repository.

Two interesting additional questions: (1) How can you fix this? I suspect using git filter-branch can fix it (by replaying commits to get "correct" tree objects), but you'd have to figure out which branch(es) contain the commits that contain those trees, and also have to purge the "bad" commits referring to the bad tree objects. (And of course this will cause all kinds of pain for anyone who cloned the repo.) (2) How did this arise in the first place?

It would be interesting to see what git cat-file prints for these trees, although git cat-file -p adds leading zeros, so it's kind of a pain. (git cat-file tree bde551ba2d6882ac7614c25305c24ddc1c75b1c4 dumps the raw contents, but they're full of binary bits. Still view-able, just need to use something that handles binary stuff.)