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

Nov 10, 2014

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 なはず。