fsck error in git repo: error: object e0af252dfe5f01f0cfec132df8c3afd85c7ef403: zeroPaddedFilemode: contains zero-padded file modes

[dkg]

When trying to clone the repo using transfer.fsckobjects=true, i see the following error:

0 dkg@alice:~$ git clone --config transfer.fsckobjects=true https://github.com/ionelmc/python-darkslide
Cloning into 'python-darkslide'...
remote: Enumerating objects: 4949, done.
remote: Counting objects: 100% (54/54), done.
remote: Compressing objects: 100% (37/37), done.
error: object e0af252dfe5f01f0cfec132df8c3afd85c7ef403: zeroPaddedFilemode: contains zero-padded file modes
fatal: fsck error in packed object
fatal: index-pack failed
128 dkg@alice:~$ 

This is likely the same as seen in ohmyzsh/ohmyzsh#4963 (see much more discussion and details on that issue). Rewriting history is a painful operation, but i think it could be useful to do this (once) for future folks who do typically run integrity checks on their repositories. (i typically have this set by default myself)

[ionelmc]

Is there any alternative? This is technically a fork... but I wouldn't like to rewrite the history for any kind of repo anyway. How did these broken commits get in in the first place?

[dkg]

yeah, rewriting history is a messy thing ☹. looks like fcca0a5894b76f6c7012ca575880e183fbd710aa (from @bradcupit back in 2010, ugh) is where at least one of the changes zero-padded modes snuck in (there are two, though):

warning in tree e0af252dfe5f01f0cfec132df8c3afd85c7ef403: zeroPaddedFilemode: contains zero-padded file modes
warning in tree a8d36ef4c0f940d9a90c238eee98367c4060086d: zeroPaddedFilemode: contains zero-padded file modes

Maybe the other one is from the other contribution by @bradcupit (d45e2db, also in 2010)? sorry i don't know enough about how to diagnose problems in the repo to be certain.

@bradcupit, do you have any ideas about what might have happened here?

Sadly, i don't know of any alternative to rewriting history (and ohmyzsh didn't seem to figure one out either). this is because the problem has two parts:

• the two tree objects in the current history are ill-formed, but they are referred to by their digest in the associated commit object.
• the commit objects themselves are included by indirect reference in all subsequent commits.

Since changing the tree object to be well-formed would change its digest, it would necessarily change the commit IDs of all subsequent commits.

I wish i had better suggestions for you, i'm sorry to be the bearer of bad news :(

(btw, thanks for darkslide! and thanks for the 16×9 themes in 6.0.0 -- very useful)

[bradcupit]

@dkg I'm of no help. Back in 2010 I was a git n00b. No idea what I did!