fsck fails on git repo

[danielcompton]

When I clone aleph, I get an error:

$ git clone --config transfer.fsckObjects=true [email protected]:ztellman/aleph.git aleph1
Cloning into 'aleph1'...
remote: Counting objects: 7831, done.
error: object 31dfaf308f5ea00c04c0653ecbe8937fb0add324: zeroPaddedFilemode: contains zero-padded file modes
fatal: Error in object
fatal: index-pack failed

I didn't actually clone with the --config setting, but the equivalent settings in ~/.gitconfig are:

# Check that any objects received are complete and correct
[transfer]
        fsckobjects = true
[fetch]
        fsckobjects = true
[receive]
        fsckObjects = true

See for a similar problem on the hub repo: https://github.com/github/hub/issues/1404

[ztellman]

This seems to correspond to tree 31dfaf308f5ea00c04c0653ecbe8937fb0add324, which as far as I can tell dates back to the very earliest commits on this project. I'm not very experienced in fixing these sorts of issues, but I can poke at it a bit. This isn't blocking you in any way, correct?

[danielcompton]

Nope no blocker. I just temporarily removed those settings while cloning, and then added local .git/config settings to disable checking.

[ztellman]

I've tried to fix this a few times. The corrupt objects are in the first few commits, but if I try to squash those commits using git rebase --root HEAD, I end up having to manually re-merge eight years worth of changes, which is pretty tedious to say the least.

I'd love to fix this, and am willing to truncate all history before 0.3.1 if that makes it simpler, but I'd need a more automatic solution than the one above.

[arnaudgeiser]

I will close this as won't fix. Yes... it' a bit annoying, but that's unlikely anyone will spend time on it.

Do not hesitate to reopen if you think this really needs to be addressed.