git-svnでloose objectがcorruptした時のヒント

git svn rebase の最中とかにたとえばマシンがお亡くなりになって、もっかい叩いたら

fatal: loose object b2460997f61ed75f4025ea7177f96afe54e5d3bc (stored in /some/where/.git/objects/b2/460997f61ed75f4025ea7177f96afe54e5d3bc) is corrupt
could not detach HEAD
rebase refs/remotes/git-svn: command returned error: 1

とか言われて身動き取れなくて泣きそうな時のヒント、というか自分用のメモ。 前提として、git-svnしか想定してない。 そもそも全revisionをSubversionリポジトリから最悪引っ張り直さないといけないから泣きそうなのであって、 リモートもGitだったり、Subversionだけど小規模だってんなら黙ってcloneし直した方がきっと早い。

まず、 git fsck をかけてcorruptだと言われるオブジェクトファイルを除けていく。 最終的にmissingなblobが絞り込めれば、そいつらを作り直せばいいだけ。 ここでもしblob以外がmissingだと言われたら、他をあたってください。

$ git fsck --full
*snip*
broken link from    tree 0b69d49c2b28cd44ab9dd117953c69898dab54ca
              to    blob b2460997f61ed75f4025ea7177f96afe54e5d3bc
broken link from    tree 0b69d49c2b28cd44ab9dd117953c69898dab54ca
              to    blob 6d987d2a105d4e1a1b6e1a0bd245bda6da1e4845
missing blob b2460997f61ed75f4025ea7177f96afe54e5d3bc
missing blob 6d987d2a105d4e1a1b6e1a0bd245bda6da1e4845

次に、既にfetchまでは終わってるはずなので、リモートブランチのログをrawフォーマットで眺める。 ハッシュで引っかければ、問題のblobの元がどのリビジョンのどのファイルなのかがわかる。

$ git log --raw remotes/git-svn
*snip*
    git-svn-id: some_repository@rev
*snip*
:100644 100644 d311938... b246099... M  path/to/one
:100644 100644 2c19eff... 6d987d2... M  path/to/another

元ファイルを svn checkout して git hash-object に食わせれば正常かつハッシュの一致するblobが手に入るはず。 それを書き戻してあげれば、オブジェクトファイルに関しては解決。

あとはワーキングコピーが中途半端にrebaseされてる可能性があるので、 ちゃんとcleanな状態に戻してあげれば晴れてOKなはず。