diff options
author | Jonathan Maw <jonathan.maw@codethink.co.uk> | 2013-09-30 15:08:10 +0100 |
---|---|---|
committer | Jonathan Maw <jonathan.maw@codethink.co.uk> | 2013-09-30 15:08:10 +0100 |
commit | 43efcf42382e87de4aa423e5e1607958ad1717d0 (patch) | |
tree | 7e19a0765b0dd6885fbdf69d3a8d0159a1b42de8 /Documentation/howto/recover-corrupted-blob-object.txt | |
parent | 45d74c4b0fe38218b4569a90da7102cf48d616c2 (diff) | |
parent | c7fd06b6411fb04eb4d9acd7f8822a288a50dc17 (diff) | |
download | git-43efcf42382e87de4aa423e5e1607958ad1717d0.tar.gz |
Merge branch 'baserock/jonathanmaw/S9007/upgrade-git' into baserock/morphbaserock/morph
Reviewed-by: Lars Wirzenius <lars.wirzenius@codethink.co.uk>
Reviewed-by: Daniel Silverstone <daniel.silverstone@codethink.co.uk>
Diffstat (limited to 'Documentation/howto/recover-corrupted-blob-object.txt')
-rw-r--r-- | Documentation/howto/recover-corrupted-blob-object.txt | 20 |
1 files changed, 15 insertions, 5 deletions
diff --git a/Documentation/howto/recover-corrupted-blob-object.txt b/Documentation/howto/recover-corrupted-blob-object.txt index 323b513ed0..1b3b188d3c 100644 --- a/Documentation/howto/recover-corrupted-blob-object.txt +++ b/Documentation/howto/recover-corrupted-blob-object.txt @@ -3,18 +3,24 @@ From: Linus Torvalds <torvalds@linux-foundation.org> Subject: corrupt object on git-gc Abstract: Some tricks to reconstruct blob objects in order to fix a corrupted repository. +Content-type: text/asciidoc +How to recover a corrupted blob object +====================================== + +----------------------------------------------------------- On Fri, 9 Nov 2007, Yossi Leybovich wrote: > > Did not help still the repository look for this object? > Any one know how can I track this object and understand which file is it +----------------------------------------------------------- -So exactly *because* the SHA1 hash is cryptographically secure, the hash +So exactly *because* the SHA-1 hash is cryptographically secure, the hash itself doesn't actually tell you anything, in order to fix a corrupt object you basically have to find the "original source" for it. The easiest way to do that is almost always to have backups, and find the -same object somewhere else. Backups really are a good idea, and git makes +same object somewhere else. Backups really are a good idea, and Git makes it pretty easy (if nothing else, just clone the repository somewhere else, and make sure that you do *not* use a hard-linked clone, and preferably not the same disk/machine). @@ -31,19 +37,23 @@ original object, so right now the corrupt object is useless, but it's very interesting for the future, in the hope that you can re-create a non-corrupt version. +----------------------------------------------------------- So: > ib]$ mv .git/objects/4b/9458b3786228369c63936db65827de3cc06200 ../ +----------------------------------------------------------- This is the right thing to do, although it's usually best to save it under -it's full SHA1 name (you just dropped the "4b" from the result ;). +it's full SHA-1 name (you just dropped the "4b" from the result ;). Let's see what that tells us: +----------------------------------------------------------- > ib]$ git-fsck --full > broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8 > to blob 4b9458b3786228369c63936db65827de3cc06200 > missing blob 4b9458b3786228369c63936db65827de3cc06200 +----------------------------------------------------------- Ok, I removed the "dangling commit" messages, because they are just messages about the fact that you probably have rebased etc, so they're not @@ -79,7 +89,7 @@ working tree, in which case fixing this problem is really simple, just do git hash-object -w my-magic-file -again, and if it outputs the missing SHA1 (4b945..) you're now all done! +again, and if it outputs the missing SHA-1 (4b945..) you're now all done! But that's the really lucky case, so let's assume that it was some older version that was broken. How do you tell which version it was? @@ -124,7 +134,7 @@ and your repository is good again! git log --raw --all and just looked for the sha of the missing object (4b9458b..) in that -whole thing. It's up to you - git does *have* a lot of information, it is +whole thing. It's up to you - Git does *have* a lot of information, it is just missing one particular blob version. Trying to recreate trees and especially commits is *much* harder. So you |