20

I believe, my Git repository is not in good shape, wherein when I do a 

git fsck

I get the following warnings at the top. 

103b5dd53f7a96f8e3a02aea0d3d4d9bb19644ed: contains zero-padded file modes
bb4729593e76f66b46292ad6ae61bfe909558337: contains zero-padded file modes
4709aa73691ce7da36dd22ccfd157c4514395330: contains zero-padded file modes

I tried the following (suggested by a colleague) to find the offending commits, so that I could correct them. I tried the following methods.

  1. Go through all the commits from git rev-list HEAD.
  2. For each of those commits, do a git ls-tree -rd to find all the relevant object SHAs.
  3. See if any of those, matches with the above in the git fsck.

The logic of the above seemed right to me, but it was not able to find the offending commit.

git rev-list --all --remotes | while read commit; do git ls-tree -rd $commit | grep -E "103b5dd53f7a96f8e3a02aea0d3d4d9bb19644ed|bb4729593e76f66b46292ad6ae61bfe909558337|4709aa73691ce7da36dd22ccfd157c4514395330" && echo -e "HIT @ $commit\n\n"; done

What are we missing here? How can we find either the offending commit or file is having the problem? At the end, I want to fix the repository.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Senthil Kumaran
  • 54,681
  • 14
  • 94
  • 131
  • Did you try a simpler grep: `grep "103b5dd53"`, just to see if at least one of those commits shows up? – VonC Feb 05 '13 at 06:28
  • Yes, I did one at a time too, and it did not show up. – Senthil Kumaran Feb 05 '13 at 06:41
  • So those SHA1s should come from an upstream repo, a bit like in http://stackoverflow.com/questions/4864740/github-repo-corruption-sha1-collision – VonC Feb 05 '13 at 06:45
  • Or it is a discrepancy of some kind: http://git.661346.n2.nabble.com/Tree-with-leading-0-modes-in-1-7-0-3-td4806618.html – VonC Feb 05 '13 at 06:50
  • Hi VonC - even if they come from upsteam, since it is DVCS, should not I be able to fix it on my local. This is not from github. And thanks for link, I too realize that someone using older git may have caused this. Not sure the nabble.com link gave any resolution to this. – Senthil Kumaran Feb 05 '13 at 07:05
  • I agree, and I am just trying to explore various leads here. Nothing definitive yet. – VonC Feb 05 '13 at 07:08
  • 1
    Have you considered rebuilding the repository and seeing if the problem persists? git fast-export --all | (cd /empty/repository && git fast-import) # that is from the git fast-export man page, for context – JosefAssad Feb 12 '13 at 08:42
  • Hi @JosefAssad - I did and that's the only way to resolve this. (You post that as an answer and I will upvote). There is a catch in that solution. All the resultant object SHA will change and tree references will not be imported - git limitation. – Senthil Kumaran Feb 12 '13 at 16:12
  • Hm. If your SHAs changed then I imagine it's related to the repo corruption and not due to the method of resolving the issue. The presence of "dangling" references in the corrupt repo does affect hash generation. So looking at it another way, the process fixes your hashes rather than changes them. :) Just a thought. – JosefAssad Feb 12 '13 at 18:30

2 Answers2

20

Adding workaround from comments as answer:

Rebuilding the repo using git fast-export and then git fast-import resolves the problem but SHA values will change and tree references are not brought over.

Create a new empty repository:

mkdir /newrepo
cd /newrepo
git init

Go back to the old one with the fsck warnings:

cd /oldrepo

Pipe the data over using fast-export from old data to fast-import in the new repo

git fast-export --all | (cd /newrepo && git fast-import)
9000
  • 39,899
  • 9
  • 66
  • 104
JosefAssad
  • 4,018
  • 28
  • 37
5

Just a supplement with @9000's answer:

Create an empty git repo in ../newrepo, and 

git fast-export --signed-tags=strip --all | (cd ../newrepo/ && git fast-import)
philant
  • 34,748
  • 11
  • 69
  • 112
NewPtone
  • 3,075
  • 1
  • 17
  • 10