Mercurialにはamendがない
git commitにある–amendというフラグをご存知だろうか。
gitでは、commitは手元のレポジトリに保存される。多人数で開発するときの中央レポジトリに反映させるには、commitしたものをpushする必要がある。……で、大抵の多人数で開発するプロジェクトの場合、commitした変更を(gerritとかの手段によって)レビューしたりしつつ、すべてが整ってから、pushするというのが一般的な流れかと思う。
だけど人間というのはうかつなことをするものだから、commitした直後に下らない間違いを犯しがちなわけだ。例えば、編集したのにChangeLogを追加してないとか。ファイル足したのにビルドファイルの変更を加え忘れたとか。そういうやつ。そういうしょうもない変更でコミットを汚したくない時のために–amendがある。–amendすると、新しいコミットを作る代わりに最新版のコミットを更新する。
実は、Darcsにもamend-recordというそのための専用コマンドがある(普通のcommitに当たるコマンドはrecordという名前になっている)。これはつまり、こういううかつなコミットはよくあって避けづらいということだ。だが、Mercurialには、この種の操作のための便利なコマンドがない。
もちろん、同じ事もできるといえばできる。hg rollbackというコマンドを実行すると最新のコミットを消してしまう。で、その後にhg commitし直せばいい(Gitユーザ向けのMercurialガイドにもそのまんま載っている)。そういうextensionを書くという手も残されていて、もちろんmqを使うという手もなくはない。
だが、なんで–amendがないんだろうね、というのを、ここではうだうだ考えたい。
すぐ思いつくのは、「非推奨の操作は面倒くさくする」の原理だ。普段良く使ってほしいオペレーションは簡単にできるようにし、あんまり使って欲しくないやつはよくわからない複雑なオペレーションにする。ちゃんとわかってない人には使わせないようにするというわけだ(この観点からすると、git reset –hardとかは最低ではないかとおもう……)。Mercurialはわりとこの原則を採用していて、hg helpでは出てこないような特殊なコマンドが実は山ほどあり、詳しい人だけが内部的なデータをうかがい知ることができるようになっている。つまり、–amendは「やればできるけど積極的にはサポートしたくない」という開発者の意思が介在していると見るべきだ。
そもそもバージョン管理システムにおいて、変更履歴というのは不変であり、勝手に消したりするべきではない。バージョンの管理というのはそういうことだ。また、amendで書き換える前のコミットを誰かがpullしてしまっていたら厄介なことになる。そういう危険はもちろんgitだろうがなんだろうがありうるので、gitのマニュアルにもYou should understand the implications of rewriting history if you amend a commit that has already been published.と注意書きが書かれている。だが、本質的に危険な処理なら、やるべきではないという主張なのではないだろうか。
ここに、理想主義的な視点を感じることができる。gitの–amendは便利さの追求でもあり、実用主義的な視点を感じる。あと私は気づかなかったが、git bisectなどのためには各コミットをクリーンに保っておく必要があり、そういうワークフローを追求した結果として–amendは必要だというわけだ。Mercurialの考え方は理想的だが、現実に立脚していない気がする。
Mercurialの側にも言い訳はある。Mercurialのextensionフレームワークは協力かつ柔軟なので、commitコマンドに–amendフラグを足すことぐらいはやればできる。作者はやりたくないが欲しいというユーザに対しては「それextensionで」と返事しておける。mqを使えば問題ないわけだし(そういえばMacHgにはamendがあるらしい。なんじゃそりゃ……)。
しかし、ここにextensionの不幸もある気もする。「それextensionで」の行き着く先は、謎の野良extensionが溢れ、統一したものが存在しない世界であり、extension同士の相性が取り沙汰される世界だ。Mercurialはそんなひどい事になっていないけど、柔軟すぎるextensionは得てして不幸ももたらす気がする……。
という以上は全く私の妄想なわけだけど、実際のところはどうなんでしょ。メーリングリストを追っても、–amendはどうもFAQっぽい気がするけどなあ。