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: >> Hi, >> >> At work we use SVN. To deal with this I mirror the svn repo with >> git-svn and have a cron job that runs git svn rebase every hour, and >> then I rebase from that git repo. >> >> Unfortunately, on the computer that runs the cron job, /home ran out >> of space. After making more space and deleting the >> svn/trunk/.rev_map, my 'git svn rebase' dies with a >>> git svn rebase >> Rebuilding .git/svn/trunk/.rev_map.4279b43a-dd95-8640-b069-b0d2992e4ff2 ... >> error: Could not read 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce >> fatal: Failed to traverse parents of commit >> 31c4379db99f05d0942e7c204b38f7b587fb4d3b >> rev-list --pretty=raw --no-color --reverse refs/remotes/trunk --: >> command returned error: 128 >> >> So I look for corruption with >>> git fsck --full --strict >> broken link from commit 31c4379db99f05d0942e7c204b38f7b587fb4d3b >> to commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce >> dangling blob a6027cd01178f19243342c0f6ccaef8fb798dcf4 >> <snipped more dangling blobs> >> dangling blob 4348d7ebd189208716b44bcf4198c1f29d18e6c3 >> missing commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce ****** >> dangling blob 22757bac2e3433cccd9d7e32fa79d90031e14353 >> dangling blob 1276575eca02976ff677b61a6873562db7db31d7 >> dangling blob f98343007ac9d2f33a81fe25f4d446b045c3167a >> dangling blob d29043a6e2b87cd0be1f3fb39f0c88283b79409b >> dangling blob f7d08b39830709c044279d17d3d85cbe813998bb >> dangling blob 64f14b305164f65c788dc9970deb7dfc79ac7446 >> >> Thankfully, I have copies of the repo and this object (3d4c2b) in >> other location and that passes git-fsck. Strangely, it is a commit >> object from about 18 month ago and should have been in a pack for a >> long time, so maybe running out of disk space was not the cause. >> >> 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. -- 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