archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Alexander Litvinov <>
Cc: Git Mailing List <>
Subject: Re: My git repo is broken, how to fix it ?
Date: Mon, 19 Mar 2007 22:34:10 -0700 (PDT)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, 20 Mar 2007, Alexander Litvinov wrote:
> Actualy, I have packed that objects already, so fsck warn me:
> $ git fsck --full
> error: packed 8edc906985f00cf27180b1d9d4c3217ffd1896f8 from .git/objects/pack/pack-abc5cbabfc05c213e50c43ea07f43158bf1de236.pack is corrupt
> error: packed f6aca57bb30a12e9ac5d71558e0b6052d6fb67a8 from .git/objects/pack/pack-abc5cbabfc05c213e50c43ea07f43158bf1de236.pack is corrupt
> sha1 mismatch 8edc906985f00cf27180b1d9d4c3217ffd1896f8
> sha1 mismatch f6aca57bb30a12e9ac5d71558e0b6052d6fb67a8

Ok, this is different from what I expected. 

Since your pack-file seems to pass its own internal SHA1 checks, it means 
that it was likely corrupt already when it was written out in the pack. 
What's interesting is that it seems to unpack, but then the SHA1 of the 
unpacked object doesn't match.

The reason I say that's interesting is that it would seem to mean that the 
zlib CRC/adler check didn't trigger - which probably means that the object 
was corrupted *before* it was compressed (but after it was originally 
SHA1-summed), or the compression itself was corrupting (eg a libz 

And since the SHA1 of the pack-file matches, the thing was apparently 
also written out "correctly" after compression (but by that "correctly" I 
obviously mean that the *corrupted* data was written out). 

Sadly, by the time it's in a pack-file, it is *really* hard to figure out 
what went wrong: I see your unpacked data, but it's really the packed raw 
objects that I wanted to look at, in case there would be some pattern in 
the actual corruption (the corruption will then result in random crud when 
actually unpacking, which is why the unpacked data isn't that interesting, 
simple because there's no pattern left to analyze - it got inflated to 
bogus "data").

> I also use autocrlf feature:
> $ git config core.autocrlf
> true

I doubt autocrlf affects anything here, it's only used at checkin and 
checkout time, and it wouldn't affect the raw internal git objects.

More interesting might be if you might be using any of the other flags 
that actually affect internal git object packing: "use_legacy_headers" in 
particular? If we have a bug there, that could be nasty.

But to really look at this we should probably add a "really_careful" flag 
that actually re-verifies the SHA1 on read so that we'd catch these kinds 
of corruptions early. 

> This files are cpp code from our project and tham need to be private. Really.

Ok, no problem. I added back the git list (but not your attachments, 
obviously) but as explained above, there is not a lot I can do with the 
unpacked data, I'd like to see the actual "raw" stuff.

I'm hoping somebody has any ideas. We really *could* check the SHA1 on 
each read (and slow down git a lot) and that would catch corruption much 
faster and hopefully pinpoint it more quickly where exactly it happens. 
But maybe somebody has some other smart idea?


  parent reply	other threads:[~2007-03-20  5:34 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-28  4:36 My git repo is broken, how to fix it ? Alexander Litvinov
2007-02-28  4:57 ` Linus Torvalds
2007-02-28 11:54   ` Alexander Litvinov
2007-02-28 16:19     ` Linus Torvalds
2007-02-28 19:12       ` Alex Riesen
2007-03-19 13:32       ` Alexander Litvinov
2007-03-19 15:20         ` Linus Torvalds
     [not found]           ` <>
2007-03-20  5:34             ` Linus Torvalds [this message]
2007-03-20  6:55               ` Alexander Litvinov
2007-03-20  7:42               ` Junio C Hamano
2007-03-20 15:23                 ` Nicolas Pitre
     [not found] ` <>
     [not found]   ` <>
     [not found]     ` <>
2007-03-22 15:58       ` Linus Torvalds
2007-03-22 16:34         ` Nicolas Pitre
     [not found]       ` <>
2007-03-22 16:17         ` Linus Torvalds
2007-03-22 16:29           ` Linus Torvalds
2007-03-22 16:48             ` Linus Torvalds
2007-03-22 17:01               ` Nicolas Pitre
2007-03-22 17:10                 ` Linus Torvalds
2007-03-22 17:28                   ` Nicolas Pitre
2007-03-22 22:13                   ` Jeff King
2007-03-23  0:25                     ` Linus Torvalds
2007-03-23  0:42                       ` Bill Lear
2007-03-23  0:51                       ` Jeff King
2007-03-22 20:31               ` [PATCH] git-apply: Do not free the wrong buffer when we convert the data for writeout Junio C Hamano
2007-03-22 20:55                 ` Linus Torvalds
2007-03-23  3:55                   ` Alexander Litvinov
2007-03-23  3:40               ` My git repo is broken, how to fix it ? Alexander Litvinov
2007-03-22 17:12             ` Johannes Sixt
2021-06-06 17:27 B
2021-06-06 17:28 B
2021-12-25  8:30 Joseph Mitchell
2021-12-26  0:48 ` Lemuria
2023-05-29 18:57 ross thomas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).