Git超えなるか？パッチ理論に基づく次世代VCS「Pijul」が熱い

Pijulは、パッチ理論（Theory of Patches）という数学的な基盤の上に構築された、革新的なオープンソースの分散型バージョン管理システムです。Gitのようなスナップショットベースではなく、変更（パッチ）そのものを管理の最小単位として扱うことで、より直感的かつ強力なマージ操作と競合の解決を実現しています。次世代の分散型システムとして注目を集めています。

最後にPijulを動かそうとしたとき（確か2年半前）、MacとLinuxでごく単純な操作をしただけでも、解決できそうにない致命的なクラッシュが多発してたんだよね。今はもうマシになったのかな？

FOSDEM 2024での（いい意味でちょっとブッ飛んでる）トークも見てみて。 https://archive.fosdem.org/2024/schedule/event/fosdem-2024-3... (https://archive.fosdem.org/2024/schedule/event/fosdem-2024-3423-version-control-post-git/)

安定性、パフォーマンス、機能の面で、今はどんな状況なの？

Pijulはいいアイデアをいくつか持ってると思うけど、現時点でのgitのネットワーク効果は強すぎる気がするな。jjの「多くのバックエンドのフロントエンドになって共通のUXを共有する」っていうコンセプトは良いと思うんだけど、既存ツール向けのpijulバックエンドがないと、流行るのは難しそう。

ホームページから引用：

なぜ？

交換法則

Pijulでは、独立した変更なら、結果やバージョンの識別子を変えることなく、どんな順序でも適用できる。これはgit rebaseやhg transplantを使うワークフローよりずっとシンプル。Pijulには「チャネル」っていうブランチみたいな機能があるけど、他のシステムほど重要じゃない。例えば、いわゆるフィーチャーブランチもPijulではただの変更に過ぎないことが多い。履歴を綺麗に保つのがデフォルトなんだ。

これ、グラフがパッチレイヤーでしかエンコードされないから、あまり意味のない特性なんだよね。現実世界ではパッチの依存関係よりも、もっとセマンティックな依存関係の方がずっと多い。例えば、別のパッチで追加された関数を呼び出す関数を追加するパッチとか。Pijulはそういうのを関知しない。

マージの正確性

Pijulはマージに関して強力なプロパティをいくつか保証してる。一番大事なのは、行の順序が常に維持されること。3ウェイマージだと行が入れ替わっちゃうことがあるけど、それとは違う。順序が不明な場合（同時編集とか）はコンフリクトになる。「自動」とか「コンフリクトなし」を謳うマージシステムとは対照的だ。

これで困った記憶はないし、解決にPijulが必要なわけでもない。git blameの情報を利用するマージアルゴリズムなら同じように機能するはず。単に、誰もそんなものを使うほど気にしてないだけ。

第一級のコンフリクト

Pijulでは、コンフリクトは「マージの失敗」じゃなくて、標準的なケースとしてモデル化されてる。具体的には、コンフリクトは2つの変更の間で発生して、1つの解決用の変更で解決される。解決用の変更は、他に並行して変更が行われていても、同じ2つの変更間のコンフリクトを解決する。一度解決すれば、コンフリクトが再発することはない。

コンフリクトの再発はGitでも別に問題じゃない。なぜかみんな、ほとんどの場合でマージを使うべきなのにリベースを使わなきゃいけないと思い込んでるんだよね。

部分クローン

交換法則のおかげで、リポジトリのごく一部だけをクローンできる。そのサブセットに関連する変更だけを適用すればいいから。部分クローンで作業して作った変更は、そのまま大きなリポジトリに送れる。

Gitとか他のスナップショットベースのSCMの方が、これに関してはよっぽど上手くやってる。Gitは特定のファイルやディレクトリだけをチェックアウトできるし、DB内のgitオブジェクトにエンコードされたツリー構造のおかげで、すごく効率的。コンテンツを遅延フェッチするためにFUSEレイヤーを構築することだってできる。Pijulでこれをやろうと思ったら、履歴をめちゃくちゃ慎重に管理しなきゃいけなくなる。例えば、2つのパッチを修正するパッチがある場合、それらの変更が必要なら永久にマージされた状態になる。リポジトリ内の全ファイルをリフォーマットしたり、トップレベルのインターフェースを変更して全ユーザーを修正したりするPRを想像してみて。あーあ、これで全部が相互依存になっちゃって、部分クローンはおしまいだ。