8

I have recently removed some folders from my git repos history using the following command:

git filter-branch --index-filter 'git rm -r --cached var' -- --all

Unfortunately I cannot pull anymore from this repos, This is the error set I'm getting:

git pull
remote: Counting objects: 3953, done.
remote: Compressing objects: 100% (2810/2810), done.
error: garbage at end of loose object '4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0'
fatal: object 4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0 is corrupted
fatal: index-pack failed
Improve this question
2
  • On which linux system did you make the changes?
    – Andres Jaan Tack
    Commented Jul 13, 2010 at 11:13
  • I was using windows; now I'm on linux and it works well
    – mnml
    Commented Jul 20, 2010 at 8:11

1 Answer 1

Reset to default
7

Some kind soul wrote a script to do this automatically (and more thoroughly), but the process to recovery is basically this:

  1. Examine the file that reports garbage, with hexdump.

    $ hexdump .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0

    You're looking for a part of the file where there's a huge span of zeros. If there are multiple such spans, I've had good luck (N = 2) when considering just the first giant set of zeros, even when they included small runs of nonzero data. This is the "garbage" that git is complaining about.

    ...
0000500 0532 0302 0000 0000 0000 0000 0000 0000    # <-- Beginning here...
0000510 0000 0000 0000 0000 0000 0000 0000 0000
*
0001000             # ... almost 3kb of zeros.

    You can determine from this the real size of the object. Here, it would be 0x504 or 1,284 bytes.

  2. Make a backup copy of the object. In case you pick the wrong set of zeros, you can try again with a different set.

    $ cp .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0 ~/old_4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0

  3. Truncate the file to its appropriate length.

    $ truncate -s 1284 .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0

The corrupt object should now be fixed. Assuming it was the only one, cloning/pushing/pulling the repository should now work as expected.

Citing my sources, I believe I have experienced the same issue, but in my case using Ubuntu 10.4 (kernel 2.6.32-23-generic). In this case, it is a filesystem bug that has not been tracked down yet. There is an open issue on ecryptfs on this subject and also a related usenet thread. Along the way to a solution, I found a handy answer and summary on StackOverflow. The linked article was very interesting, though I ultimately went a different way.

Improve this answer
1
  • HUGE thank you for this answer. git-remove-trailing-garbage.py (your link with text "wrote a script", above) saved my bacon when I ran into that same ecryptfs bug you mentioned!
    – Adam Monsen
    Commented Apr 11, 2011 at 21:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .