On Tue, Aug 11, 2009 at 1:49 PM, Bryan Donlan<bdonlan@xxxxxxxxx> wrote: > On Tue, Aug 11, 2009 at 4:48 PM, Bryan Donlan<bdonlan@xxxxxxxxx> wrote: >> On Tue, Aug 11, 2009 at 4:15 PM, tarmigan<tarmigan+lists@xxxxxxxxx> wrote: >>> I would rather not copy the whole good repo back to the one that ran >>> out of space because it's multiple gigs. My plan is to just explode >>> the bad pack on of the corrupted repo, explode good pack and then, >>> copy the corrupted object back. So my question is how do I tell which >>> pack contains that object? (I would rather not explode all the packs >>> because of the repo size.) Is there a way to extract a single object >>> from a pack without exploding the whole pack? >> >> You should be able to just extract the single object in question: >> >> goodrepo$ git cat-file commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce >> > ~/commit.dat >> goodrepo$ cd ~/badrepo >> badrepo$ git read-file -t commit ~/commit.dat >> (should output 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce) >> >> At this point your repo should be repaired. >> > > Err, that should read git hash-object, not git read-file. > Thanks, and thanks to Junio who also responded with something similar off-list. I was vaguely familiar with cat-file and hash-object before but didn't realize how they could be used to do what I wanted, so thanks for the lesson. As Junio suspected, I after the next fsck, I also had problems with the tree associated with that commit and also the commits behind that one. Each fsck takes around 12 minutes, so replacing one commit at a time seemed not very productive. So now I am doing another svn clone from scratch and letting it run for a few hours (it was a straight mirror, so nothing is lost). It seems somewhat wasteful, but I guess better a few hours of cpu time than a few hours of my time. Thanks, Tarmigan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html