{"thread":{"id":"10764","subject":"Re: corrupt object on git-gc","startedAt":"2007-11-09T13:38:39Z","lastAt":"2007-11-26T02:12:19Z","messageCount":20,"participants":["Yossi Leybovich","Andreas Ericsson","Johannes Sixt","Nicolas Pitre","Linus Torvalds","Johannes Schindelin","Mike Hommey","J. Bruce Fields"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"59041","messageId":"4fe79b4b0711090538wf483ce7j89c518962e89780e@mail.gmail.com","threadId":"10764","inReplyTo":null,"subject":"Re: corrupt object on git-gc","fromName":"Yossi Leybovich","fromEmail":"sleybo@gmail.com","sentAt":"2007-11-09T13:38:39Z","receivedAt":"2007-11-09T13:38:39Z","isPatch":false,"sender":{"key":"sleybo@gmail.com","avatar":null},"body":"Yossi Leybovich wrote:\n>> Hi\n>>\n>> I know its loose but still I think there are references in the\n>> repository to this object.\n>> How I can remove it from the repository ?\n>>\n\n>That was not a very good idea. You just moved ALL objects whose hash\n>begin with 4b out of the object database.\n\n>Try only moving the offending file out of the 4b directory.\n\nDid not help still the repository look for this object?\nAny one know how can I track this object and understand which file is it\n\n\n\nib]$ mv .git/objects/4b/9458b3786228369c63936db65827de3cc06200 ../\n\nib]$ git-fsck --full\ndangling commit 0d43a63623237385e432572bf61171713dcd8e98\ndangling commit 4fc6b1127e4a7f4ff5b65a2dd8a90779b5aff3e0\ndangling commit 7da607374fe2b1ae09228d2035dd608c73dad7c8\ndangling commit 004ef09ae022c60a30f9cd61f90d18df5db3628e\ndangling commit 85112c6fabb6b8913ab244a8645d67380616eba6\nbroken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8\n to blob 4b9458b3786228369c63936db65827de3cc06200\nmissing blob 4b9458b3786228369c63936db65827de3cc06200\ndangling commit bd98481afa93356fa6daa4b6f88c4e631ae2fd72\ndangling commit e81e3d2c9c25e5bf5b31327b10b23f9bd0a6d056\ndangling commit 92ff9b8cbc771345c9cde0c7fef2c23bb79242b9\n"},{"id":"59045","messageId":"473464A2.7080003@op5.se","threadId":"10764","inReplyTo":"4fe79b4b0711090538wf483ce7j89c518962e89780e@mail.gmail.com","subject":"Re: corrupt object on git-gc","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-09T13:46:10Z","receivedAt":"2007-11-09T13:46:10Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Yossi Leybovich wrote:\n> Yossi Leybovich wrote:\n>>> Hi\n>>>\n>>> I know its loose but still I think there are references in the\n>>> repository to this object.\n>>> How I can remove it from the repository ?\n>>>\n> \n>> That was not a very good idea. You just moved ALL objects whose hash\n>> begin with 4b out of the object database.\n> \n>> Try only moving the offending file out of the 4b directory.\n> \n> Did not help still the repository look for this object?\n> Any one know how can I track this object and understand which file is it\n> \n\nIs this a super-secret project or you can make a tarball of the .git\ndirectory and send it to me? Trying to track down the cause through\nemail is decidedly slow.\n\n> \n> \n> ib]$ mv .git/objects/4b/9458b3786228369c63936db65827de3cc06200 ../\n> \n> ib]$ git-fsck --full\n> dangling commit 0d43a63623237385e432572bf61171713dcd8e98\n> dangling commit 4fc6b1127e4a7f4ff5b65a2dd8a90779b5aff3e0\n> dangling commit 7da607374fe2b1ae09228d2035dd608c73dad7c8\n> dangling commit 004ef09ae022c60a30f9cd61f90d18df5db3628e\n> dangling commit 85112c6fabb6b8913ab244a8645d67380616eba6\n> broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8\n> to blob 4b9458b3786228369c63936db65827de3cc06200\n\nOne tree uses the object. I'm not sure if any commit-objects\nuse the tree. Try\n\nfor b in $(git branch --no-color -a | cut -b3-); do\nfor rev in $(git rev-list HEAD); do\n\tgit ls-tree -r $rev | grep -q 2d9263c6d23595e7cb2a21e5ebbb53655278dff8\n\ttest $? -eq 0 && echo $rev && break\ndone\ndone\n\nIf it turns up empty, you *should* be able to safely delete\n2d9263c6d23595e7cb2a21e5ebbb53655278dff8 and \n4b9458b3786228369c63936db65827de3cc06200\n\nMake sure to take a backup first though.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"59061","messageId":"4fe79b4b0711090701g7a43cdfdi5e20e5ffb437d7bb@mail.gmail.com","threadId":"10764","inReplyTo":"473464A2.7080003@op5.se","subject":"Re: corrupt object on git-gc","fromName":"Yossi Leybovich","fromEmail":"sleybo@gmail.com","sentAt":"2007-11-09T15:01:29Z","receivedAt":"2007-11-09T15:01:29Z","isPatch":false,"sender":{"key":"sleybo@gmail.com","avatar":null},"body":"On Nov 9, 2007 8:46 AM, Andreas Ericsson wrote:\n>\n> Is this a super-secret project or you can make a tarball of the .git\n> directory and send it to me? Trying to track down the cause through\n> email is decidedly slow.\n>\n\nActually yes , I am not sure I can send the repository , I will\nfarther check that.\n>\n> One tree uses the object. I'm not sure if any commit-objects\n> use the tree. Try\n>\n> for b in $(git branch --no-color -a | cut -b3-); do\n> for rev in $(git rev-list HEAD); do\n> git ls-tree -r $rev | grep -q 2d9263c6d23595e7cb2a21e5ebbb53655278dff8\n> test $? -eq 0 && echo $rev && break\n> done\n> done\n\ntried this and it return empty\n\n[mellanox@mellanox-compile ib]$\n[mellanox@mellanox-compile ib]$ for b in $(git branch --no-color -a |\ncut -b3-); do\n> for rev in $(git rev-list HEAD); do\n> git ls-tree -r $rev | grep -q 2d9263c6d23595e7cb2a21e5ebbb53655278dff8;\n> test $? -eq 0 && echo $rev && break;\n> done; done\n[mellanox@mellanox-compile ib]$\n[mellanox@mellanox-compile ib]$\n\n[BTW I didn't notice u use the b varieble so I also tried gi rev-list\n$b but still empty ]\nI also tried to remove object and tree and apperently other trees and\ncommits reference to these objects\n\n mv ../9458b3786228369c63936db65827de3cc06200 ../4b/\nmv: cannot stat `../9458b3786228369c63936db65827de3cc06200': No such\nfile or directory\n[mellanox@mellanox-compile ib]$ mv\n.git/objects/4b/9458b3786228369c63936db65827de3cc06200 ../4b/\n[mellanox@mellanox-compile ib]$ mv\n.git/objects/2d/9263c6d23595e7cb2a21e5ebbb53655278dff8 ../2d/\n[mellanox@mellanox-compile ib]$ git-fsck --full\nbroken link from tree e5a0044c4ccae7635f07414c1f155bac72d25fd9\n to tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8\ndangling commit 0d43a63623237385e432572bf61171713dcd8e98\ndangling commit 4fc6b1127e4a7f4ff5b65a2dd8a90779b5aff3e0\ndangling commit 7da607374fe2b1ae09228d2035dd608c73dad7c8\ndangling commit 004ef09ae022c60a30f9cd61f90d18df5db3628e\nbroken link from tree 8bd00402b2a20024f4556107b8a729b0205657db\n to tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8\ndangling commit 85112c6fabb6b8913ab244a8645d67380616eba6\nmissing tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8\ndangling commit bd98481afa93356fa6daa4b6f88c4e631ae2fd72\ndangling commit e81e3d2c9c25e5bf5b31327b10b23f9bd0a6d056\ndangling commit 92ff9b8cbc771345c9cde0c7fef2c23bb79242b9\n\n\n\n>\n> If it turns up empty, you *should* be able to safely delete\n> 2d9263c6d23595e7cb2a21e5ebbb53655278dff8 and\n> 4b9458b3786228369c63936db65827de3cc06200\n>\n> Make sure to take a backup first though.\n\na lot of commits and trees point to this\n\n>\n> --\n> Andreas Ericsson andreas.ericsson@op5.se\n> OP5 AB www.op5.se\n> Tel: +46 8-230225 Fax: +46 8-230231\n>\n"},{"id":"59066","messageId":"47347E0E.1040205@viscovery.net","threadId":"10764","inReplyTo":"4fe79b4b0711090701g7a43cdfdi5e20e5ffb437d7bb@mail.gmail.com","subject":"Re: corrupt object on git-gc","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-11-09T15:34:38Z","receivedAt":"2007-11-09T15:34:38Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Yossi Leybovich schrieb:\n> [about corrupt loose object '4b9458b3786228369c63936db65827de3cc06200']\n\nYou can try to create a clone (after you have fixed up the artificial \nbreakages that you made). If that goes well, then the bad object is \nreferenced only from reflogs.\n\n-- Hannes\n"},{"id":"59068","messageId":"4fe79b4b0711090753r52abd3e1ree64271c0fa229f6@mail.gmail.com","threadId":"10764","inReplyTo":"47347E0E.1040205@viscovery.net","subject":"Re: corrupt object on git-gc","fromName":"Yossi Leybovich","fromEmail":"sleybo@gmail.com","sentAt":"2007-11-09T15:53:46Z","receivedAt":"2007-11-09T15:53:46Z","isPatch":false,"sender":{"key":"sleybo@gmail.com","avatar":null},"body":"On Nov 9, 2007 10:34 AM, Johannes Sixt wrote:\n> Yossi Leybovich schrieb:\n> > [about corrupt loose object '4b9458b3786228369c63936db65827de3cc06200']\n>\n> You can try to create a clone (after you have fixed up the artificial\n> breakages that you made). If that goes well, then the bad object is\n> referenced only from reflogs.\n>\n\n\ngit clone ib ib-clone\nInitialized empty Git repository in /home/mellanox/work/symm/ib-clone/.git/\n0 blocks\n\n\n\n[mellanox@mellanox-compile ib-clone]$ cd ib-clone/\n\n[mellanox@mellanox-compile ib-clone]$ git branch -a\n* mlx4\n origin/HEAD\n origin/master\n origin/mlx4\n origin/mlx4-work\n origin/mthca\n origin/second_port\n\n\n[mellanox@mellanox-compile ib-clone]$ git-gc\nGenerating pack...\nDone counting 3288 objects.\nDeltifying 3288 objects...\nerror: corrupt loose object '4b9458b3786228369c63936db65827de3cc06200'\nfatal: object 4b9458b3786228369c63936db65827de3cc06200 cannot be read\nerror: failed to run repack\n\n\nSo still I cant pack my repository\n\n\n> -- Hannes\n>\n>\n"},{"id":"59070","messageId":"473484CB.9060804@viscovery.net","threadId":"10764","inReplyTo":"4fe79b4b0711090753r52abd3e1ree64271c0fa229f6@mail.gmail.com","subject":"Re: corrupt object on git-gc","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-11-09T16:03:23Z","receivedAt":"2007-11-09T16:03:23Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Yossi Leybovich schrieb:\n> On Nov 9, 2007 10:34 AM, Johannes Sixt wrote:\n>> Yossi Leybovich schrieb:\n>>> [about corrupt loose object '4b9458b3786228369c63936db65827de3cc06200']\n>> You can try to create a clone (after you have fixed up the artificial\n>> breakages that you made). If that goes well, then the bad object is\n>> referenced only from reflogs.\n>>\n> \n> \n> git clone ib ib-clone\n> Initialized empty Git repository in /home/mellanox/work/symm/ib-clone/.git/\n> 0 blocks\n\nMake this:\n\n git clone file:///home/mellanox/work/symm/ib ib-clone\n\notherwise you get a hard-linked identical copy, but you want to use the git \nprotocol to create the clone.\n\n-- Hannes\n"},{"id":"59071","messageId":"alpine.LFD.0.9999.0711091102370.21255@xanadu.home","threadId":"10764","inReplyTo":"4fe79b4b0711090753r52abd3e1ree64271c0fa229f6@mail.gmail.com","subject":"Re: corrupt object on git-gc","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-09T16:03:35Z","receivedAt":"2007-11-09T16:03:35Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 9 Nov 2007, Yossi Leybovich wrote:\n\n> On Nov 9, 2007 10:34 AM, Johannes Sixt wrote:\n> > Yossi Leybovich schrieb:\n> > > [about corrupt loose object '4b9458b3786228369c63936db65827de3cc06200']\n> >\n> > You can try to create a clone (after you have fixed up the artificial\n> > breakages that you made). If that goes well, then the bad object is\n> > referenced only from reflogs.\n> >\n> \n> \n> git clone ib ib-clone\n> Initialized empty Git repository in /home/mellanox/work/symm/ib-clone/.git/\n> 0 blocks\n\nPlease try \"file://ib\" instead. Otherwise the clone will only hardlink \nfiles to the original repository.\n\n\nNicolas\n"},{"id":"59077","messageId":"alpine.LFD.0.999.0711090758560.15101@woody.linux-foundation.org","threadId":"10764","inReplyTo":"4fe79b4b0711090538wf483ce7j89c518962e89780e@mail.gmail.com","subject":"Re: corrupt object on git-gc","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-11-09T16:28:38Z","receivedAt":"2007-11-09T16:28:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 9 Nov 2007, Yossi Leybovich wrote:\n> \n> Did not help still the repository look for this object?\n> Any one know how can I track this object and understand which file is it\n\nSo exactly *becuse* the SHA1 hash is cryptographically secure, the hash \nitself doesn't actually tell you anything, in order to fix a corrupt \nobject you basically have to find the \"original source\" for it. \n\nThe easiest way to do that is almost always to have backups, and find the \nsame object somewhere else. Backups really are a good idea, and git makes \nit pretty easy (if nothing else, just clone the repository somewhere else, \nand make sure that you do *not* use a hard-linked clone, and preferably \nnot the same disk/machine).\n\nBut since you don't seem to have backups right now, the good news is that \nespecially with a single blob being corrupt, these things *are* somewhat \ndebuggable.\n\nFirst off, move the corrupt object away, and *save* it. The most common \ncause of corruption so far has been memory corruption, but even so, there \nare people who would be interested in seeing the corruption - but it's \nbasically impossible to judge the corruption until we can also see the \noriginal object, so right now the corrupt object is useless, but it's very \ninteresting for the future, in the hope that you can re-create a \nnon-corrupt version.\n\nSo:\n\n> ib]$ mv .git/objects/4b/9458b3786228369c63936db65827de3cc06200 ../\n\nThis is the right thing to do, although it's usually best to save it under \nit's full SHA1 name (you just dropped the \"4b\" from the result ;).\n\nLet's see what that tells us:\n\n> ib]$ git-fsck --full\n> broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8\n> to blob 4b9458b3786228369c63936db65827de3cc06200\n> missing blob 4b9458b3786228369c63936db65827de3cc06200\n\nOk, I removed the \"dangling commit\" messages, because they are just \nmessages about the fact that you probably have rebased etc, so they're not \nat all interesting. But what remains is still very useful. In particular, \nwe now know which tree points to it!\n\nNow you can do\n\n\tgit ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8\n\nwhich will show something like\n\n\t100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8 .gitignore\n\t100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883 .mailmap\n\t100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c COPYING\n\t100644 blob ee909f2cc49e54f0799a4739d24c4cb9151ae453 CREDITS\n\t040000 tree 0f5f709c17ad89e72bdbbef6ea221c69807009f6 Documentation\n\t100644 blob 1570d248ad9237e4fa6e4d079336b9da62d9ba32 Kbuild\n\t100644 blob 1c7c229a092665b11cd46a25dbd40feeb31661d9 MAINTAINERS\n\t...\n\nand you should now have a line that looks like\n\n\t10064 blob 4b9458b3786228369c63936db65827de3cc06200\tmy-magic-file\n\nin the output. This already tells you a *lot* it tells you what file the \ncorrupt blob came from!\n\nNow, it doesn't tell you quite enough, though: it doesn't tell what \n*version* of the file didn't get correctly written! You might be really \nlucky, and it may be the version that you already have checked out in your \nworking tree, in which case fixing this problem is really simple, just do\n\n\tgit hash-object -w my-magic-file\n\nagain, and if it outputs the missing SHA1 (4b945..) you're now all done!\n\nBut that's the really lucky case, so let's assume that it was some older \nversion that was broken. How do you tell which version it was?\n\nThe easiest way to do it is to do\n\n\tgit log --raw --all --full-history -- subdirectory/my-magic-file \n\nand that will show you the whole log for that file (please realize that \nthe tree you had may not be the top-level tree, so you need to figure out \nwhich subdirectory it was in on your own), and because you're asking for \nraw output, you'll now get something like\n\n\tcommit abc\n\tAuthor:\n\tDate:\n\t ..\n\t:100644 100644 4b9458b... newsha... M somedirectory/my-magic-file\n\n\n\tcommit xyz\n\tAuthor:\n\tDate:\n\t\n\t ..\n\t:100644 100644 oldsha... 4b9458b... M\tsomedirectory/my-magic-file\n\nand this actually tells you what the *previous* and *subsequent* versions \nof that file were! So now you can look at those (\"oldsha\" and \"newsha\" \nrespectively), and hopefully you have done commits often, and can \nre-create the missing my-magic-file version by looking at those older and \nnewer versions!\n\nIf you can do that, you can now recreate the missing object with\n\n\tgit hash-object -w \n\nand your repository is good again!\n\n(Btw, you could have ignored the fsck, and started with doing a \n\n\tgit log --raw --all\n\nand just looked for the sha of the missing object (4b9458b..) in that \nwhole thing. It's up to you - git does *have* a lot of information, it is \njust missing one particular blob version.\n\nTrying to recreate trees and especially commits is *much* harder. So you \nwere lucky that it's a blob. It's quite possible that you can recreate the \nthing.\n\n\t\t\tLinus\n"},{"id":"59078","messageId":"4fe79b4b0711090831o30d2880dh3d9ec0bb0503f77a@mail.gmail.com","threadId":"10764","inReplyTo":"alpine.LFD.0.9999.0711091102370.21255@xanadu.home","subject":"Re: corrupt object on git-gc","fromName":"Yossi Leybovich","fromEmail":"sleybo@gmail.com","sentAt":"2007-11-09T16:31:51Z","receivedAt":"2007-11-09T16:31:51Z","isPatch":false,"sender":{"key":"sleybo@gmail.com","avatar":null},"body":"On Nov 9, 2007 11:03 AM, Nicolas Pitre wrote:\n> On Fri, 9 Nov 2007, Yossi Leybovich wrote:\n>\n> > On Nov 9, 2007 10:34 AM, Johannes Sixt wrote:\n> > > Yossi Leybovich schrieb:\n> > > > [about corrupt loose object '4b9458b3786228369c63936db65827de3cc06200']\n> > >\n> > > You can try to create a clone (after you have fixed up the artificial\n> > > breakages that you made). If that goes well, then the bad object is\n> > > referenced only from reflogs.\n> > >\n> >\n> >\n> > git clone ib ib-clone\n> > Initialized empty Git repository in /home/mellanox/work/symm/ib-clone/.git/\n> > 0 blocks\n>\n> Please try \"file://ib\" instead. Otherwise the clone will only hardlink\n> files to the original repository.\n>\n>\n\nAnd agian the corruption pop up again , so clone does not help\n\n\n[mellanox@mellanox-compile ib]$ git clone file://ib ib-clone\nInitialized empty Git repository in /home/mellanox/work/symm/ib-clone/.git/\nremote: Generating pack...\nremote: Counting objects: 276\nDone counting 3288 objects.\nremote: Deltifying 3288 objects...\nremote: error: remote: corrupt loose object\n'4b9458b3786228369c63936db65827de3cc06200'remote:\nremote: fatal: remote: object 4b9458b3786228369c63936db65827de3cc06200\ncannot be readremote:\nerror: git-upload-pack: git-pack-objects died with error.\nremote: aborting due to possible repository corruption on the remote side.\nfatal: early EOF\nfatal: index-pack died with error code 128\nfetch-pack from 'file://ib' failed.\nfatal: git-upload-pack: aborting due to possible repository corruption\non the remote side.\n\n\n> Nicolas\n>\n"},{"id":"59083","messageId":"alpine.LFD.0.9999.0711091149050.21255@xanadu.home","threadId":"10764","inReplyTo":"4fe79b4b0711090831o30d2880dh3d9ec0bb0503f77a@mail.gmail.com","subject":"Re: corrupt object on git-gc","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-09T16:52:17Z","receivedAt":"2007-11-09T16:52:17Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 9 Nov 2007, Yossi Leybovich wrote:\n\n> On Nov 9, 2007 11:03 AM, Nicolas Pitre wrote:\n> > On Fri, 9 Nov 2007, Yossi Leybovich wrote:\n> >\n> > > On Nov 9, 2007 10:34 AM, Johannes Sixt wrote:\n> > > > Yossi Leybovich schrieb:\n> > > > > [about corrupt loose object '4b9458b3786228369c63936db65827de3cc06200']\n> > > >\n> > > > You can try to create a clone (after you have fixed up the artificial\n> > > > breakages that you made). If that goes well, then the bad object is\n> > > > referenced only from reflogs.\n> > > >\n> > >\n> > >\n> > > git clone ib ib-clone\n> > > Initialized empty Git repository in /home/mellanox/work/symm/ib-clone/.git/\n> > > 0 blocks\n> >\n> > Please try \"file://ib\" instead. Otherwise the clone will only hardlink\n> > files to the original repository.\n> >\n> >\n> \n> And agian the corruption pop up again , so clone does not help\n\nOK that means that the object is really part of your active history.\n\nLinus just posted a nice summary of your only option left. If you \nmanage to recreate the damaged object then it would be nice of you if \nyou could provide us with both the bad and the good one for analysis.\n\n\nNicolas\n"},{"id":"59090","messageId":"alpine.LFD.0.9999.0711091221210.21255@xanadu.home","threadId":"10764","inReplyTo":"alpine.LFD.0.999.0711090758560.15101@woody.linux-foundation.org","subject":"[PATCH] add a howto document about corrupted blob recovery","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-09T17:28:19Z","receivedAt":"2007-11-09T17:28:19Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"Extracted from a post by Linus on the mailing list.\n\nSigned-off-by: Nicolas Pitre \n---\n\nOn Fri, 9 Nov 2007, Linus Torvalds wrote:\n\n> But since you don't seem to have backups right now, the good news is that \n> especially with a single blob being corrupt, these things *are* somewhat \n> debuggable.\n\nI was in the process of writing a similar message, but Linus was quicker \nand his version is actually much nicer. Certainly good howto material.\n\ndiff --git a/Documentation/howto/recover-corrupted-blob-object.txt b/Documentation/howto/recover-corrupted-blob-object.txt\nnew file mode 100644\nindex 0000000..9b6853c\n--- /dev/null\n+++ b/Documentation/howto/recover-corrupted-blob-object.txt\n@@ -0,0 +1,134 @@\n+Date: Fri, 9 Nov 2007 08:28:38 -0800 (PST)\n+From: Linus Torvalds \n+Subject: corrupt object on git-gc\n+Abstract: Some tricks to reconstruct blob objects in order to fix\n+ a corrupted repository.\n+\n+On Fri, 9 Nov 2007, Yossi Leybovich wrote:\n+> \n+> Did not help still the repository look for this object?\n+> Any one know how can I track this object and understand which file is it\n+\n+So exactly *because* the SHA1 hash is cryptographically secure, the hash \n+itself doesn't actually tell you anything, in order to fix a corrupt \n+object you basically have to find the \"original source\" for it. \n+\n+The easiest way to do that is almost always to have backups, and find the \n+same object somewhere else. Backups really are a good idea, and git makes \n+it pretty easy (if nothing else, just clone the repository somewhere else, \n+and make sure that you do *not* use a hard-linked clone, and preferably \n+not the same disk/machine).\n+\n+But since you don't seem to have backups right now, the good news is that \n+especially with a single blob being corrupt, these things *are* somewhat \n+debuggable.\n+\n+First off, move the corrupt object away, and *save* it. The most common \n+cause of corruption so far has been memory corruption, but even so, there \n+are people who would be interested in seeing the corruption - but it's \n+basically impossible to judge the corruption until we can also see the \n+original object, so right now the corrupt object is useless, but it's very \n+interesting for the future, in the hope that you can re-create a \n+non-corrupt version.\n+\n+So:\n+\n+> ib]$ mv .git/objects/4b/9458b3786228369c63936db65827de3cc06200 ../\n+\n+This is the right thing to do, although it's usually best to save it under \n+it's full SHA1 name (you just dropped the \"4b\" from the result ;).\n+\n+Let's see what that tells us:\n+\n+> ib]$ git-fsck --full\n+> broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8\n+> to blob 4b9458b3786228369c63936db65827de3cc06200\n+> missing blob 4b9458b3786228369c63936db65827de3cc06200\n+\n+Ok, I removed the \"dangling commit\" messages, because they are just \n+messages about the fact that you probably have rebased etc, so they're not \n+at all interesting. But what remains is still very useful. In particular, \n+we now know which tree points to it!\n+\n+Now you can do\n+\n+\tgit ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8\n+\n+which will show something like\n+\n+\t100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8 .gitignore\n+\t100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883 .mailmap\n+\t100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c COPYING\n+\t100644 blob ee909f2cc49e54f0799a4739d24c4cb9151ae453 CREDITS\n+\t040000 tree 0f5f709c17ad89e72bdbbef6ea221c69807009f6 Documentation\n+\t100644 blob 1570d248ad9237e4fa6e4d079336b9da62d9ba32 Kbuild\n+\t100644 blob 1c7c229a092665b11cd46a25dbd40feeb31661d9 MAINTAINERS\n+\t...\n+\n+and you should now have a line that looks like\n+\n+\t10064 blob 4b9458b3786228369c63936db65827de3cc06200\tmy-magic-file\n+\n+in the output. This already tells you a *lot* it tells you what file the \n+corrupt blob came from!\n+\n+Now, it doesn't tell you quite enough, though: it doesn't tell what \n+*version* of the file didn't get correctly written! You might be really \n+lucky, and it may be the version that you already have checked out in your \n+working tree, in which case fixing this problem is really simple, just do\n+\n+\tgit hash-object -w my-magic-file\n+\n+again, and if it outputs the missing SHA1 (4b945..) you're now all done!\n+\n+But that's the really lucky case, so let's assume that it was some older \n+version that was broken. How do you tell which version it was?\n+\n+The easiest way to do it is to do\n+\n+\tgit log --raw --all --full-history -- subdirectory/my-magic-file \n+\n+and that will show you the whole log for that file (please realize that \n+the tree you had may not be the top-level tree, so you need to figure out \n+which subdirectory it was in on your own), and because you're asking for \n+raw output, you'll now get something like\n+\n+\tcommit abc\n+\tAuthor:\n+\tDate:\n+\t ..\n+\t:100644 100644 4b9458b... newsha... M somedirectory/my-magic-file\n+\n+\n+\tcommit xyz\n+\tAuthor:\n+\tDate:\n+\t\n+\t ..\n+\t:100644 100644 oldsha... 4b9458b... M\tsomedirectory/my-magic-file\n+\n+and this actually tells you what the *previous* and *subsequent* versions \n+of that file were! So now you can look at those (\"oldsha\" and \"newsha\" \n+respectively), and hopefully you have done commits often, and can \n+re-create the missing my-magic-file version by looking at those older and \n+newer versions!\n+\n+If you can do that, you can now recreate the missing object with\n+\n+\tgit hash-object -w \n+\n+and your repository is good again!\n+\n+(Btw, you could have ignored the fsck, and started with doing a \n+\n+\tgit log --raw --all\n+\n+and just looked for the sha of the missing object (4b9458b..) in that \n+whole thing. It's up to you - git does *have* a lot of information, it is \n+just missing one particular blob version.\n+\n+Trying to recreate trees and especially commits is *much* harder. So you \n+were lucky that it's a blob. It's quite possible that you can recreate the \n+thing.\n+\n+\t\t\tLinus\n"},{"id":"59091","messageId":"Pine.LNX.4.64.0711091730010.4362@racer.site","threadId":"10764","inReplyTo":"alpine.LFD.0.9999.0711091221210.21255@xanadu.home","subject":"Re: [PATCH] add a howto document about corrupted blob recovery","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-09T17:30:30Z","receivedAt":"2007-11-09T17:30:30Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 9 Nov 2007, Nicolas Pitre wrote:\n\n> Extracted from a post by Linus on the mailing list.\n\nHeh. I was hoping that somebody would be quicker than me...\n\nCiao,\nDscho\n"},{"id":"59098","messageId":"4fe79b4b0711090953h5b06f7d4l2d17972630a4d355@mail.gmail.com","threadId":"10764","inReplyTo":"alpine.LFD.0.999.0711090758560.15101@woody.linux-foundation.org","subject":"Re: corrupt object on git-gc","fromName":"Yossi Leybovich","fromEmail":"sleybo@gmail.com","sentAt":"2007-11-09T17:53:51Z","receivedAt":"2007-11-09T17:53:51Z","isPatch":false,"sender":{"key":"sleybo@gmail.com","avatar":null},"body":"On Nov 9, 2007 11:28 AM, Linus Torvalds wrote:\n> and you should now have a line that looks like\n>\n> 10064 blob 4b9458b3786228369c63936db65827de3cc06200 my-magic-file\n\nThat works and now I know the file\n>\n> The easiest way to do it is to do\n>\n> git log --raw --all --full-history -- subdirectory/my-magic-file\n>\n> and that will show you the whole log for that file (please realize that\n> the tree you had may not be the top-level tree, so you need to figure out\n> which subdirectory it was in on your own), and because you're asking for\n> raw output, you'll now get something like\n>\n> commit abc\n> Author:\n> Date:\n> ..\n> :100644 100644 4b9458b... newsha... M somedirectory/my-magic-file\n>\n>\n> commit xyz\n> Author:\n> Date:\n>\n> ..\n> :100644 100644 oldsha... 4b9458b... M somedirectory/my-magic-file\n>\n> and this actually tells you what the *previous* and *subsequent* versions\n> of that file were! So now you can look at those (\"oldsha\" and \"newsha\"\n> respectively), and hopefully you have done commits often, and can\n> re-create the missing my-magic-file version by looking at those older and\n> newer versions!\n>\n> If you can do that, you can now recreate the missing object with\n\nOk, tried that and unfortuantly the SHA1 number is apear only one\n\n[mellanox@mellanox-compile ib]$ git log --raw --all --full-history --\nSymmK/St.c | grep 4b9\n:100755 100755 308806c... 4b9458b3786228369c63936db65827de3cc06200 M\n SymmK/St.c\n\ngit log --raw --all --full-history -- SymmK/St.c\n\n...\n...\ncommit 597e70e7dc8e06a7cdbe4d9e9727411c964bd023\nAuthor: sleybo \nDate: Fri Oct 5 10:41:43 2007 -0400\n\n 1. increase QPs parameters - QP is bigger than 4k\n 2. lock buffers use the dma key\n 3. add prints\n\n:100755 100755 308806c... 4b9458b3786228369c63936db65827de3cc06200 M\n SymmK/St.c\n\n\nWhat intersting is that the SHA1 that I looked for apear only once\n(only as new SHA1)\n\nSo I checkout version of the file which produce the old SHA1 308806c....\n\n[mellanox@mellanox-compile ib-tmp]$ git checkout mlx4-start -- SymmK/St.c\n[mellanox@mellanox-compile ib-tmp]$ git hash-object -w SymmK/St.c\n308806cf3a864656a49d00edc35b9505abd627a2\n\nthan I did\n[mellanox@mellanox-compile ib-tmp]$ git diff-tree --stdin -p --pretty\n597e70e7dc8e06a7cdbe4d9e9727411c964bd023 > commit-597e70e\n\n( which is the commit SHA1)\n\n[mellanox@mellanox-compile ib-tmp]$ git apply commit-597e70e\nAdds trailing whitespace.\n../ib/commit-597e70e:1622:\nAdds trailing whitespace.\n../ib/commit-597e70e:1646: (int)devif->lock_dma +\nlockid*sizeof(u64),\nwarning: 2 lines add whitespace errors.\n[mellanox@mellanox-compile ib-tmp]$ git hash-object -w SymmK/St.c\ne69de29bb2d1d6434b8b29ae775ad8c2e48c5391\n\n\nSo the same commit actual lead to the wrong SHA1\n(I tried this flow on different file and it works)\n\nI think I am close but still not there , any suggestions ?\n\nThanks\nYossi\n"},{"id":"59099","messageId":"alpine.LFD.0.999.0711091000310.15101@woody.linux-foundation.org","threadId":"10764","inReplyTo":"4fe79b4b0711090953h5b06f7d4l2d17972630a4d355@mail.gmail.com","subject":"Re: corrupt object on git-gc","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-11-09T18:02:43Z","receivedAt":"2007-11-09T18:02:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 9 Nov 2007, Yossi Leybovich wrote:\n> \n> Ok, tried that and unfortuantly the SHA1 number is apear only one\n> \n> [mellanox@mellanox-compile ib]$ git log --raw --all --full-history --\n> SymmK/St.c | grep 4b9\n> :100755 100755 308806c... 4b9458b3786228369c63936db65827de3cc06200 M SymmK/St.c\n\nActually, that's not at all \"unfortunately\", because that implies that \nit's the very *latest* version of that \"SymmK/St.c\" file. I really think \nyou already had it checked out, but didn't try my first suggestion of just \ndoing \"git hash-object -w SymmK/St.c\" which likely would have fixed it \nalready (unless you had changed it in your working tree, of course!)\n\n\t\tLinus\n"},{"id":"59109","messageId":"4fe79b4b0711091037g8c6c048h29b7d387e75d62bb@mail.gmail.com","threadId":"10764","inReplyTo":"alpine.LFD.0.999.0711091000310.15101@woody.linux-foundation.org","subject":"Re: corrupt object on git-gc","fromName":"Yossi Leybovich","fromEmail":"sleybo@gmail.com","sentAt":"2007-11-09T18:37:35Z","receivedAt":"2007-11-09T18:37:35Z","isPatch":false,"sender":{"key":"sleybo@gmail.com","avatar":null},"body":"On Nov 9, 2007 1:02 PM, Linus Torvalds wrote:\n>\n>\n> On Fri, 9 Nov 2007, Yossi Leybovich wrote:\n> >\n> > Ok, tried that and unfortuantly the SHA1 number is apear only one\n> >\n> > [mellanox@mellanox-compile ib]$ git log --raw --all --full-history --\n> > SymmK/St.c | grep 4b9\n> > :100755 100755 308806c... 4b9458b3786228369c63936db65827de3cc06200 M SymmK/St.c\n>\n> Actually, that's not at all \"unfortunately\", because that implies that\n> it's the very *latest* version of that \"SymmK/St.c\" file. I really think\n> you already had it checked out, but didn't try my first suggestion of just\n> doing \"git hash-object -w SymmK/St.c\" which likely would have fixed it\n> already (unless you had changed it in your working tree, of course!)\n>\nIts very old version of the file.\nWhat interesting is the second part of the experiment\nI tried to apply the same commit on this file and it leaded to different SHA1\n\n\n\n\n> Linus\n>\n"},{"id":"59114","messageId":"alpine.LFD.0.999.0711091050230.15101@woody.linux-foundation.org","threadId":"10764","inReplyTo":"4fe79b4b0711091037g8c6c048h29b7d387e75d62bb@mail.gmail.com","subject":"Re: corrupt object on git-gc","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-11-09T18:55:03Z","receivedAt":"2007-11-09T18:55:03Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 9 Nov 2007, Yossi Leybovich wrote:\n>\n> What interesting is the second part of the experiment\n> I tried to apply the same commit on this file and it leaded to different SHA1\n\nEh. That commit was basically corrupt, because the blob had gotten \nremoved. I don't even understand how git diff-tree gave a diff with that \nfile at all (side note: I'd also suggest you just use \"git show \" \ninstead of that complex and _really_ old git-diff-tree incantation).\n\nSo no, you didn't \"apply the same commit\". \n\nBut if you have the diff somewhere (perhaps email archive? you sent it to \nsomebody?) or you can re-create it exactly, then..\n\n\t\tLinus\n"},{"id":"59115","messageId":"20071109190707.GA17864@glandium.org","threadId":"10764","inReplyTo":"alpine.LFD.0.999.0711091050230.15101@woody.linux-foundation.org","subject":"Re: corrupt object on git-gc","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-11-09T19:07:07Z","receivedAt":"2007-11-09T19:07:07Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Fri, Nov 09, 2007 at 10:55:03AM -0800, Linus Torvalds wrote:\n> \n> \n> On Fri, 9 Nov 2007, Yossi Leybovich wrote:\n> >\n> > What interesting is the second part of the experiment\n> > I tried to apply the same commit on this file and it leaded to different SHA1\n> \n> Eh. That commit was basically corrupt, because the blob had gotten \n> removed. I don't even understand how git diff-tree gave a diff with that \n> file at all (side note: I'd also suggest you just use \"git show \" \n> instead of that complex and _really_ old git-diff-tree incantation).\n> \n> So no, you didn't \"apply the same commit\". \n> \n> But if you have the diff somewhere (perhaps email archive? you sent it to \n> somebody?) or you can re-create it exactly, then..\n\nOr maybe just from memory, by looking at the diff between the previous version\nand the next version of the file.\n\nMike\n"},{"id":"59119","messageId":"4fe79b4b0711091141i38044a5o1ef940d9c7afd58f@mail.gmail.com","threadId":"10764","inReplyTo":"20071109190707.GA17864@glandium.org","subject":"Re: corrupt object on git-gc","fromName":"Yossi Leybovich","fromEmail":"sleybo@gmail.com","sentAt":"2007-11-09T19:41:05Z","receivedAt":"2007-11-09T19:41:05Z","isPatch":false,"sender":{"key":"sleybo@gmail.com","avatar":null},"body":"What I do notice is that this commit involve few files. most of the\nfile the commit generate the right next SHA1\nonly for one file its generate broken SHA1\n\n>From the git show I can see that the file which end up\ncorrupted is actually being totaly remove from\n\ndiff --git a/SymmK/St.c b/SymmK/St.c\nindex 308806c..4b9458b 100755\n--- a/SymmK/St.c\n+++ b/SymmK/St.c\n@@ -1,1535 +0,0 @@\n-MODULE_ALIAS(m_st);\n-\n-#include \n-#include \n-#include \n-#include \n-#include \n-#include \"ib_global_init.h\"\n....\n.....\n....\n\n\nWhile I tried to delete the whole file and I did not get the right SHA1\nIs this soud familiar to some one ?\nmaybe its releated to issue with some kind of white character I cant see.\n\nYossi\n"},{"id":"59120","messageId":"20071109195237.GA20030@glandium.org","threadId":"10764","inReplyTo":"4fe79b4b0711091141i38044a5o1ef940d9c7afd58f@mail.gmail.com","subject":"Re: corrupt object on git-gc","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-11-09T19:52:37Z","receivedAt":"2007-11-09T19:52:37Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Fri, Nov 09, 2007 at 02:41:05PM -0500, Yossi Leybovich wrote:\n> What I do notice is that this commit involve few files. most of the\n> file the commit generate the right next SHA1\n> only for one file its generate broken SHA1\n> \n> From the git show I can see that the file which end up\n> corrupted is actually being totaly remove from\n> \n> diff --git a/SymmK/St.c b/SymmK/St.c\n> index 308806c..4b9458b 100755\n> --- a/SymmK/St.c\n> +++ b/SymmK/St.c\n> @@ -1,1535 +0,0 @@\n> -MODULE_ALIAS(m_st);\n> -\n> -#include \n> -#include \n> -#include \n> -#include \n> -#include \n> -#include \"ib_global_init.h\"\n> ....\n> .....\n> ....\n> \n> \n> While I tried to delete the whole file and I did not get the right SHA1\n> Is this soud familiar to some one ?\n> maybe its releated to issue with some kind of white character I cant see.\n\nBecause the blob is corrupted, git show can't display the correct diff.\nYou have to guess it by yourself ! The best you can do is look at the\ndiff for this file between its previous version and the one just after\nthe corrupted version.\n\nMike\n"},{"id":"60897","messageId":"20071126021219.GH23820@fieldses.org","threadId":"10764","inReplyTo":"alpine.LFD.0.9999.0711091221210.21255@xanadu.home","subject":"Re: [PATCH] add a howto document about corrupted blob recovery","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-26T02:12:19Z","receivedAt":"2007-11-26T02:12:19Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Fri, Nov 09, 2007 at 12:28:19PM -0500, Nicolas Pitre wrote:\n> Extracted from a post by Linus on the mailing list.\n> \n> Signed-off-by: Nicolas Pitre \n\nI rearranged this some more and added it to the manual, assuming that\nmakes sense to everyone.\n\nI think there needs to be some discussion of pack objects and stuff too\nsome day. I added a few mail archive references to the \"todo\" section.\n\n--b.\n\ncommit d6e199cb6ff911e8e3e39c8b7021512a14ea79a5\nAuthor: J. Bruce Fields \nDate: Sat Mar 3 22:53:37 2007 -0500\n\n user-manual: recovering from corruption\n \n Some instructions on dealing with corruption of the object database.\n \n Most of this text is from an example by Linus, identified by Nicolas\n Pitre with a little further editing by me.\n \n Signed-off-by: \"J. Bruce Fields\" \n\ndiff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\nindex c027353..3166fb6 100644\n--- a/Documentation/user-manual.txt\n+++ b/Documentation/user-manual.txt\n@@ -1554,6 +1554,11 @@ This may be time-consuming. Unlike most other git operations (including\n git-gc when run without any options), it is not safe to prune while\n other git operations are in progress in the same repository.\n \n+If gitlink:git-fsck[1] complains about sha1 mismatches or missing\n+objects, you may have a much more serious problem; your best option is\n+probably restoring from backups. See\n+<> for a detailed discussion.\n+\n [[recovering-lost-changes]]\n Recovering lost changes\n ~~~~~~~~~~~~~~~~~~~~~~~\n@@ -3172,6 +3177,127 @@ confusing and scary messages, but it won't actually do anything bad. In\n contrast, running \"git prune\" while somebody is actively changing the\n repository is a *BAD* idea).\n \n+[[recovering-from-repository-corruption]]\n+Recovering from repository corruption\n+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n+\n+By design, git treats data trusted to it with caution. However, even in\n+the absence of bugs in git itself, it is still possible that hardware or\n+operating system errors could corrupt data.\n+\n+The first defense against such problems is backups. You can back up a\n+git directory using clone, or just using cp, tar, or any other backup\n+mechanism.\n+\n+As a last resort, you can search for the corrupted objects and attempt\n+to replace them by hand. Back up your repository before attempting this\n+in case you corrupt things even more in the process.\n+\n+We'll assume that the problem is a single missing or corrupted blob,\n+which is sometimes a solveable problem. (Recovering missing trees and\n+especially commits is *much* harder).\n+\n+Before starting, verify that there is corruption, and figure out where\n+it is with gitlink:git-fsck[1]; this may be time-consuming.\n+\n+Assume the output looks like this:\n+\n+------------------------------------------------\n+$ git-fsck --full\n+broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8\n+ to blob 4b9458b3786228369c63936db65827de3cc06200\n+missing blob 4b9458b3786228369c63936db65827de3cc06200\n+------------------------------------------------\n+\n+(Typically there will be some \"dangling object\" messages too, but they\n+aren't interesting.)\n+\n+Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6\n+points to it. If you could find just one copy of that missing blob\n+object, possibly in some other repository, you could move it into\n+.git/objects/4b/9458b3... and be done. Suppose you can't. You can\n+still examine the tree that pointed to it with gitlink:git-ls-tree[1],\n+which might output something like:\n+\n+------------------------------------------------\n+$ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8\n+100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8\t.gitignore\n+100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883\t.mailmap\n+100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c\tCOPYING\n+...\n+100644 blob 4b9458b3786228369c63936db65827de3cc06200\tmyfile\n+...\n+------------------------------------------------\n+\n+So now you know that the missing blob was the data for a file named\n+\"myfile\". And chances are you can also identify the directory--let's\n+say it's in \"somedirectory\". If you're lucky the missing copy might be\n+the same as the copy you have checked out in your working tree at\n+\"somedirectory/myfile\"; you can test whether that's right with\n+gitlink:git-hash-object[1]:\n+\n+------------------------------------------------\n+$ git hash-object -w somedirectory/myfile\n+------------------------------------------------\n+\n+which will create and store a blob object with the contents of\n+somedirectory/myfile, and output the sha1 of that object. if you're\n+extremely lucky it might be 4b9458b3786228369c63936db65827de3cc06200, in\n+which case you've guessed right, and the corruption is fixed!\n+\n+Otherwise, you need more information. How do you tell which version of\n+the file has been lost?\n+\n+The easiest way to do this is with:\n+\n+------------------------------------------------\n+$ git log --raw --all --full-history -- somedirectory/myfile\n+------------------------------------------------\n+\n+Because you're asking for raw output, you'll now get something like\n+\n+------------------------------------------------\n+commit abc\n+Author:\n+Date:\n+...\n+:100644 100644 4b9458b... newsha... M somedirectory/myfile\n+\n+\n+commit xyz\n+Author:\n+Date:\n+\n+...\n+:100644 100644 oldsha... 4b9458b... M somedirectory/myfile\n+------------------------------------------------\n+\n+This tells you that the immediately preceding version of the file was\n+\"newsha\", and that the immediately following version was \"oldsha\".\n+You also know the commit messages that went with the change from oldsha\n+to 4b9458b and with the change from 4b9458b to newsha.\n+\n+If you've been committing small enough changes, you may now have a good\n+shot at reconstructing the contents of the in-between state 4b9458b.\n+\n+If you can do that, you can now recreate the missing object with\n+\n+------------------------------------------------\n+$ git hash-object -w \n+------------------------------------------------\n+\n+and your repository is good again!\n+\n+(Btw, you could have ignored the fsck, and started with doing a \n+\n+------------------------------------------------\n+$ git log --raw --all\n+------------------------------------------------\n+\n+and just looked for the sha of the missing object (4b9458b..) in that \n+whole thing. It's up to you - git does *have* a lot of information, it is \n+just missing one particular blob version.\n+\n [[the-index]]\n The index\n -----------\n@@ -4381,4 +4507,7 @@ Write a chapter on using plumbing and writing scripts.\n \n Alternates, clone -reference, etc.\n \n-git unpack-objects -r for recovery\n+More on recovery from repository corruption. See:\n+\thttp://marc.theaimsgroup.com/?l=git&m=117263864820799&w=2\n+\thttp://marc.theaimsgroup.com/?l=git&m=117147855503798&w=2\n+\thttp://marc.theaimsgroup.com/?l=git&m=117147855503798&w=2\n"}]}