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
72347a233e6f3c176059a28f0817de6654ef29c7)
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
our
stream position. So we actually want zlib to "uncompress" even an
empty
object.
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").
Linus
-
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
