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

親父から「スピーカー処分しようと思うけど要るか？」とメールが来たので、ホイホイもらってきた。

そこそこお高いだけあって、すごくいい。2000円ちょいの中華アンプで鳴らすのが申し訳なくなるくらい。

ちょっと前に書いた、既存のblosxom用テキスト群からGitリポジトリを作るスクリプト。 git init したワーキングコピーにドバッとテキストを置いて叩くと、各ファイルのmtimeを元にコミット日時を設定して個別にコミットしてくれる。

#!/bin/bash
find . -name \*.txt | sort | while read file; do
    time="`stat --format=%Y $file` +0900"
    git add $file
    env GIT_AUTHOR_DATE="$time" GIT_COMMITTER_DATE="$time" \
        git commit -m 'initial revision' $file
done

まぁ、これを書いたきっかけは「テキストをGit管理できたらナウいんじゃね？」という単なる思いつきで、生の .gitを直接データとして見にいくblosxomプラグインもちょっと書いてはみたんだけど、

• 履歴をどうテンプレートに渡して展開するのか
  • 標準のテンプレートじゃ無理だろ
• 本当に些細なtypoやマークアップの修正も問答無用で更新扱いにするのか
  • さらに言えば、その些細な修正の履歴が見えたところで誰得なのか
• diff見せなきゃ旨味半減だけど、そのインタフェースをどう用意するのか

とか考え始めたらいろいろめんどくさくなったので、きっとこのままお蔵入りだろうな。