dotfiles icon indicating copy to clipboard operation
dotfiles copied to clipboard

zero padded filemode in your git history

Open tacaswell opened this issue 8 years ago • 7 comments

Trying to clone dotfiles with modern (well, fine bleeding edge) git fails:

✔ ~ 
00:39 $ git clone https://github.com/holman/dotfiles.git
Cloning into 'dotfiles'...
remote: Counting objects: 2026, done.
error: object 3aadee53f1ea498f2e496d63ac24cf28b358b9b7: zeroPaddedFilemode: contains zero-padded file modes
fatal: Error in object
fatal: index-pack failed

This seems to be due to a bug from 2005 + closing a security hole https://www.perforce.com/blog/150109/git-out-vulnerability-out-fire.

git config fetch.fsckObjects false

Will allow the repo to be cloned, but presumably there is a reason the default has been changed to true.

If you follow the directions (git fast-export --all | (cd ../myFixedRepo; git fast-import)) the issue seems to start very early in the history.

I have pushed the cleaned version here

tacaswell avatar Mar 14 '16 04:03 tacaswell

ad0452a260e13e06945384d5ddbf1a6761e40810 Is the last 'good' commit in the current history.

tacaswell avatar Mar 14 '16 04:03 tacaswell

Well, fuck.

What version are you running, though? I just tried on 2.7.3 on Mac (the latest release) and had no problems cloning.

Would really hope to avoid changing the SHAs on the whole repo with a force push. :\

holman avatar Mar 14 '16 16:03 holman

Ah, right. Forgot about your whole comment.

› git fsck
Checking object directories: 100% (256/256), done.
warning in tree 3aadee53f1ea498f2e496d63ac24cf28b358b9b7: zeroPaddedFilemode: contains zero-padded file modes
Checking objects: 100% (2026/2026), done.

I'm guessing this would mean most people wouldn't run into this? Will need to think things over a bit to consider what the best approach is.

Open to some thoughts by those in the peanut gallery!

holman avatar Mar 14 '16 16:03 holman

Sorry, I confused my self, the issue was not a new version of git, it was me having

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

in my .gitconfig on one of my machines and first tried to clone this repo just after updating git on that machine, so placed the blame in the wrong place.

So, it is a problem, but less so than I initially made it out to be.

One of your commit messages said something about tequila...

tacaswell avatar Mar 14 '16 17:03 tacaswell

According to this release of git 2.6, you should be able to ignore certain fsck errors with git config --global fsck.<msg-id> ignore, where msg-id would be zeroPaddedFilemode in this case.

I've tried this after a user notified me of the error (https://github.com/robbyrussell/oh-my-zsh/issues/4963) but the error still appears when cloning, but not when doing a git fsck. So I think there must be some kind of bug with at least git 2.8.0.rc3 which is the version I have.

Anyhow, you can try the above solution and see if it works.

mcornella avatar Mar 31 '16 18:03 mcornella

I've tried this after a user notified me of the error (robbyrussell/oh-my-zsh#4963) but the error still appears when cloning, but not when doing a git fsck. So I think there must be some kind of bug with at least git 2.8.0.rc3 which is the version I have.

http://thread.gmane.org/gmane.comp.version-control.git/288336

ryneeverett avatar Apr 15 '16 02:04 ryneeverett

Thanks! That's exactly it, it seems the setting is not implemented on fetch.fsck.*. Direct link: http://thread.gmane.org/gmane.comp.version-control.git/288336

mcornella avatar Apr 15 '16 02:04 mcornella