From: Linus Torvalds <torvalds@linux-foundation.org>
To: Bill Lear <rael@zopyra.com>
Cc: Junio C Hamano <junkio@cox.net>, git@vger.kernel.org
Subject: Re: Error converting from 1.4.4.1 to 1.5.0?
Date: Wed, 14 Feb 2007 10:19:53 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0702140958440.3604@woody.linux-foundation.org> (raw)
In-Reply-To: <17875.17647.74882.218627@lisa.zopyra.com>
On Wed, 14 Feb 2007, Bill Lear wrote:
>
> % git fsck-objects --full
> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
This in itself could have been due to a historical buglet that shouldn't
matter (SHA1 on pack-files got miscomputed). However, that's probably NOT
the problem, since:
> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27
implies that the pack really is corrupt.
Even a single-bit error will corrupt a pack in bad ways, which is one
reason why we're so careful with it and add its own SHA1 to the end.
The best way to proceed:
- MAKE A BACKUP ("tar" up everything). If for no other reason than
(a) then you don't have to worry about making things worse even by
mistake
(b) it might be interesting for others (if you can make those
pack-files available) to try to figure out what exactly the
corruption was. We've done it before, when it turned out to be a
single-bit error.
- if you have other git archives or just back-ups of everything, just use
them, and throw the corrupt one away entirely (but see above on why
it's nice to have an archive of the corruption for posterity anyway)
- if you don't, you can try "git unpack-objects -r". See the man-page on
why you need to first _move_ the pack-file away:
mv <bad-pack-file> .git/bad-pack.pack
mv <bad-pack-index> .git/bad-index.index
git unpack-objects -r < .git/bad-pack.pack
this will unpack as many objects into loose format as it can. Hopefully
you haven't lost much.
- after that, the ones that you *did* lose, you can hopefully find in
older git repos: even if you didn't have the *full* new repo anywhere
else, other git repositories may have the particular objects that got
corrupted. "git fsck" will tell you what is missing, and you can just
point your .git/info/alternates file at other repositories to "steal"
objects from automatically.
- if you aren't missing any objects after that, you can now repack the
repository, and then remove the alternates file:
git repack -a -d
rm .git/info/alternates
because the repack will steal all the objects you need, and thus you
don't need alternates any more.
Finally: it would be very interesting to hear if you do something strange
or unusual that could have made your chances of getting corruption higher.
Have you ever seen random SIGSEV's or strange oopses, which could be a
sign of memory corruption on your machine? Do you do a lot of things over
NFS? (which really can corrupt things, especially in circumstances with
dodgy ethernet chips: the UDP checksums are very weak, and some ethernet
cards do not do a good job of checking the ethernet CRC's!).
> So, all I did was try to do a commit with the new git ... haven't
> recloned, or pulled from upstream...
Yes, don't do anything more (certainly do *not* repack or anything) until
you have tarred up and saved the current state, and then only _after_ you
have a good safe archive to restart from, try to fix it up.
And if you can make the git history available to outsiders, I'd love to
see the corrupt tar-file (it doesn't have to be *public*, if you just can
trust me and perhaps a few other people with the data).
So far, as far as I can recall, we've certainly had people screw up their
own trees by mistake, but apart from that kind of "user error" things, the
only real corruption I recall was the single-bit error in a pack-file. We
were able to recover that, but in general, for safety, the best way to
protect your data is to replicate it across multiple independent machines
(something that git is _good_ at, happily).
Linus
next prev parent reply other threads:[~2007-02-14 18:20 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-14 16:12 Error converting from 1.4.4.1 to 1.5.0? Bill Lear
2007-02-14 17:07 ` Bill Lear
2007-02-14 17:15 ` Junio C Hamano
2007-02-14 17:20 ` Bill Lear
2007-02-14 17:45 ` Junio C Hamano
2007-02-14 20:49 ` Bill Lear
2007-02-14 20:58 ` Bill Lear
2007-02-14 21:19 ` Linus Torvalds
2007-02-14 21:40 ` Bill Lear
2007-02-14 21:47 ` Junio C Hamano
2007-02-14 21:52 ` Junio C Hamano
2007-02-14 22:04 ` Johannes Schindelin
2007-02-14 22:13 ` Junio C Hamano
2007-02-14 22:32 ` Johannes Schindelin
2007-02-15 0:41 ` Jakub Narebski
2007-02-15 0:54 ` Olivier Galibert
2007-02-15 1:36 ` Johannes Schindelin
2007-02-14 22:02 ` Johannes Schindelin
2007-02-14 22:27 ` Nicolas Pitre
2007-02-14 22:41 ` Bill Lear
2007-02-15 1:18 ` OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?) Simon 'corecode' Schubert
2007-02-15 2:13 ` Shawn O. Pearce
2007-02-15 2:51 ` Linus Torvalds
2007-02-15 10:24 ` Johannes Schindelin
2007-02-15 13:13 ` Michael K. Edwards
2007-02-15 11:58 ` Bill Lear
2007-02-15 9:13 ` Andy Parkins
2007-02-15 14:30 ` Mark Wooding
2007-02-14 23:24 ` Error converting from 1.4.4.1 to 1.5.0? Linus Torvalds
2007-02-14 23:03 ` Linus Torvalds
2007-02-15 8:40 ` Uwe Kleine-König
2007-02-14 21:12 ` Junio C Hamano
2007-02-14 21:18 ` Bill Lear
2007-02-14 21:14 ` Nicolas Pitre
2007-02-14 21:32 ` Junio C Hamano
2007-02-14 18:19 ` Linus Torvalds [this message]
2007-02-14 18:42 ` Linus Torvalds
2007-02-14 21:13 ` Bill Lear
2007-02-14 21:35 ` Linus Torvalds
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0702140958440.3604@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=rael@zopyra.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).