Repo contains invalid Git objects (zeroPaddedFilemode)

[lvh]

Attempting to git clone with fsck enabled results in an error:

❯ git clone https://github.com/squint-cljs/cherry/
Cloning into 'cherry'...
remote: Enumerating objects: 2756, done.
remote: Counting objects: 100% (41/41), done.
remote: Compressing objects: 100% (30/30), done.
remote: Total 2756 (delta 18), reused 27 (delta 11), pack-reused 2715
error: object 3ebf8cb9f283e531f511a78f3198bd0050b452f8: zeroPaddedFilemode: contains zero-padded file modes
fatal: fsck error in packed object
fatal: fetch-pack: invalid index-pack output

Git does not typically come configured to perform these checks automatically on fetch, but you can recreate this either by enabling fsck, for example by adding the following to your gitconfig:

[fetch]
    fsckObjects = true
[transfer]
    fsckObjects = true
[receive]
    fsckObjects = true

.... or running git fsck on an existing repo.

It looks like this problem dates back to 2010 (!) back when the code was called "scriptjure":

❯ git cat-file -p $badtree                                
100644 blob af24f6d2b22ff4ce4a6e990a59c3007b5e72b91b    README.markdown
100644 blob e3e62315330b8e13f4edb2db791950c45e43287d    project.clj
040000 tree 49d841d491ca05a36948eb6bedd8503cd51c9c4e    src
040000 tree 7a73a6de405c5df7b1221548a3c24c0972955d34    test

You can see that the mode indeed starts with a 0 in violation of git's file format. That bad tree first occurred here:

commit 2746d7d8c67d7b0f3b17f11a1a599e239ff83b4e
Author: Allen Rohner <arohner@gmail.com>
Date:   Sat Apr 24 15:29:25 2010 -0500

    Adds cljs, cljs*. Update tests, readme. Bump version number.

    Conflicts:

            project.clj

Presumably at the time someone was using e.g. a Git client built into an IDE or something that did not us the real git binaries and hence produced slightly malformed content. Modern git is able to handle this fine.

We could technically fix this with a git fast-export + fast-import. but that will break hashes. I'm posting this ticket in case there's an interest in doing that and making sure there's a ticket (even a closed one) for the next person who runs into this problem.

Assuming the project is not interested in fixing the malformed history fixed (and breaking hashes in the process), people who have this problem can make fsck-on-receive/transfer/fetch treat this as a warning instead of a fatal error by adding the following to their git config:

[receive "fsck"]
    zeroPaddedFilemode = warn
[transfer "fsck"]
    zeroPaddedFilemode = warn
[fetch "fsck"]
    zeroPaddedFilemode = warn

Feel free to close this if deemed not actionable, which is honestly fair. Like I said: still filing it anyway so there's a search target for the next person.

[borkdude]

It looks like this problem dates back to 2010 (!) back when the code was called "scriptjure":

LOL!

I think rewriting the history isn't really that great. What would be the next best option?

[lvh]

I think the next best option is to close this ticket and do nothing; the fact that it exists means the next person who runs into this problem has an easy workaround already documented for them :) Plus the error message is very specific so I think discoverability will be ~100%. Thanks for taking a look!

[borkdude]

Thanks!