On Sat, 9 Jul 2005, Junio C Hamano wrote:
> >>>>> "RK" == Russell King <[EMAIL PROTECTED]> writes:
> >> $ mv .git/objects/pack/* .git/
> >> $ for i in .git/*.pack; do git-unpack-objects < $i; done
> >> Unpacking 55435 objects
> >> fatal: inflate returned -3

Ahh, damn. 

> >> so it seems that the pack is corrupt... or something.

No, I htink you're using cogito-0.12, and I fixed this one-liner that 
didn't make it into cogito:

        diff-tree 291ec0f2d2ce65e5ccb876b46d6468af49ddb82e (from 
        Author: Linus Torvalds <[EMAIL PROTECTED]>
        Date:   Tue Jul 5 17:06:09 2005 -0700
            Don't special-case a zero-sized compression.
            zlib actually writes a header for that case, and while ignoring that
            header will get us the right data, it will also end up messing up 
            stream position.  So we actually want zlib to "uncompress" even an 
        diff --git a/unpack-objects.c b/unpack-objects.c
        --- a/unpack-objects.c
        +++ b/unpack-objects.c
        @@ -55,8 +55,6 @@ static void *get_data(unsigned long size
                z_stream stream;
                void *buf = xmalloc(size);
        -       if (!size)
        -               return buf;
                memset(&stream, 0, sizeof(stream));
                stream.next_out = buf;

(well, I guess it's a two-liner.).

What happens is that there's one zero-sized blob in the kernel archive 
history, and when we pack it, we pack it as a 8-byte "compressed" thing 
(hey, zlib has a header, that's normal), but when we unpack it, because we 
notice that the result is zero, we'd just skip the zlib header.

Which was wrong, because now the _next_ object will try to unpack at the 
wrong offset, and that explains why you get -3 ("bad data").

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to