今回のゲストは，分散バージョン管理システムGitのメンテナで『入門Git』（⁠注1）の著者，濱野純さんです。Linuxカーネルの開発者，Linus Torvaldsさんから引き継いでGitのメンテナになった経緯から，対談スタートです。

※1）

濱野 純（Junio C Hamano）著／秀和システム／ISBN978-4-7980-2380-9

Gitに関わった経緯

弾：Gitに関わったきっかけは？

濱：2005年の4月にLinuxカーネルのバージョン管理システムとして使われていたBitKeeperが使えなくなる（注2）からということで，Linus君がいろいろありものを探したんだけど，使えるものがなくて，誰かがいいのを作ってくれるまでのつなぎというつもりで，とりあえず自分でもコードを書いた，というアナウンスをしました。それをカーネルメーリングリスト（ML）で見ていたんですが，たまたまボクの本業がプロジェクトとプロジェクトの合間だったんです。なんかおもしろそうなこと始まってるじゃん，ということで，彼が書いたコードをダウンロードしてみたら，1,244行しかなくて。

弾：全部Cですか？

濱：そうですね。そのくらいだったら，2時間で読めるでしょ。隅から隅まで読んでみると，すごくきれいに書けてるので感心して。ボクは基本的にカーネルの開発者でもなんでもなくて，カーネルMLもちょっと眺めてただけっていう感じでした。でも，何十万行もあるカーネルのソースに関わるのはたいへんかもしれないけど，1,200行くらいから始まるこのプロジェクトなら今から入ってもおもしろいことができるかな，っていうのがGitに関わった動機の1つ。当時，1週間くらいの間にいろんなことが起こったんですけど，Linuxのカーネル開発者はLinusがわけのわからないものを使うと言ってるから，俺たちも使わせられるんだろう，あんまりひどいものを使わせられたんじゃかなわないって言うんで，力を貸して良くしようとしていました。それで自分も，全体のプロジェクトの流れを俯瞰（ふかん⁠）⁠ して，本当に必要なものは何かと考えてみると，とりあえずコミットはできるようになって，前の版からの差分も見られるようになった。でも，マージがなかったんです。Linus君がもともとマージはこんな形でやりたいというアウトラインを何回かポストしていたんですが。

弾：Linusが一番文句付けてたところですよね，既存のバージョン管理システムで。

濱：彼はCとシェルでしか書かないものですから，このマージのロジックくらいになるとさすがにかなり複雑だからスクリプト言語かなんかで誰かさらっと書いてくれたほうがいいんだけどな，みたいなことを，何回もMLに投げてたんです。でも誰も食いつかなかったんですよ。それで1週間くらい，ずーっとMLを見て勉強して，Linus君がやろうとしているマージのアルゴリズムをちょっとPerlで書いてみたっていうのを投稿した。それがボクの一番初めのある程度の規模のコントリビューションです。けど，そのときに丁寧にテストケースを，こういうときにはこうって場合分けのテーブルを30個くらい書いたんですけど，それから6時間くらいして，Linus君が自分のツリーにコミットしたマージのやり方は全然違うものだったんですよ。もっとすごい別のやり方考えたから，これで行くよって。見ると確かにコロンブスの卵で，ボクは今までMLでこんな形でやるよってLinus君が説明していたのに従って，丁寧にコードを書いたわけだけど，確かにそれを全部捨ててしまうくらいすっきりした，おもしろいやり方だったんです。誰かやってくれないかって言うからやってあげたのにってカチンときそうなものなんだけど（笑⁠）⁠，そのときに全然そうではなかったのは，もちろんボクが聖人君子だからじゃなくて，それだけすごいものがあったんです。

注2）

開発元のBitMover社がオープンソースプロジェクトに対して許していた無料使用のライセンス供与を取り止めたため。

コロンブスの卵

弾：どうコロンブスの卵だったんですか？

濱：ボクはBitKeeper使ったことないんですけど，BitKeeperのやり方は基本的にワークツリーに自分のファイルがあるとすると，その中ではマージしないそうなんです。テンポラリディレクトリみたいなものを作って，そこにマージした結果を開いて，コンフリクトがあるものはそっちで解消して，その結果をコミットしたものが自分が普段使っているワークツリーに開かれて，それでマージ完了になる。そういう形だったらしくて，もともとそれを踏襲したような形にするつもりだったらしいんだけど，結局そうしても最後にマージコンフリクトを解消した結果を，実際にコミットしてしまう前に，一度テストしたいよね。そうするとワークツリーの中で直接，テンポラリディレクトリを使わずにマージできたほうがいいよね，っていうことになって…。Gitでコミットする前に，次のコミットに入れるファイルの内容を登録しておくインデックスがあるんですけど，そのインデックスは当初，1対1だったのをやめにして，ステージという概念を導入すると言い出したんです。どういうことかというと，もともと3ウェイマージをするものだから，最初のバージョンから私はこんな変更をしました。あなたはこんな変更をしました。という差分を持ってきてマージする。じゃあ，この3つをステージ1，2，3っていうふうにインデックスに登録して，それでマージすればいいじゃん，とLinus君がいきなり言いだしたんです。確かにそうするといろいろおもしろいことができる。一番単純な例としては，私もあなたも何もしなかった場合。そしたら結果はもとのまま。それから私は何かしたけど，あなたは何もしなかった場合。そしたら私の結果をとればいいし，その反対も同様です。で，1つおもしろいと思ったのが，実は私もあなたも同じことをしたっていうケースなんです。

弾：結構あります（笑⁠）⁠。

濱：使ってみると実は確かにそうなんだけど，特にLinuxカーネルのプロジェクトは，MLベースでしょ。だから同じパッチを見て，これはうちのサブシステムもフィックスだからって拾った，だけど，実は別の人も拾ってたとかいうことがある。そういう場合分けというのはインデックスの中で全部できてしまうので，効率もいいし，非常に見通しがいい。

Linusのマネージャとしての資質

濱：それと彼は，よくメンテナの仕事の半分はNoって言うことだっていう言い方をするんですけど，人のパッチを捨てるっていうときにも，パッチというか，この変更はペケなんだけど，でもそれはお前がペケなんじゃないよって，すごく人を大事にした捨て方をするんですよね。それがすごいなと思って。ボクのときも，コードは捨てるけど，君のテストケースはそのまま使えるはずだから，こういう形でマージを作ってみたんだけど，やってみてって言われて。

弾：それ，いいなあ。

濱：人がしたことを無駄にしてないんだよというのを相手に知らしめると，コントリビュータのモチベーションを下げないで済むんですよね。新しいマージのやり方っていう発想もすごかったんだけど，コミュニティマネージャとして，人を使うマネージャとしての資質もすごい人だなと。それではまっちゃいましたね（笑⁠）⁠。