- Manyana は Bram Cohen が開発した CRDT ベースのバージョン管理プロトタイプで、マージコンフリクトをなくし、履歴を構造的に保存する新しいアプローチを提示している
- CRDT(Conflict-Free Replicated Data Type) を活用することでマージは常に成功し、コンフリクトは単なる 情報表示として扱われる ため、ユーザーは変更内容を明確に認識できる
- 行順序の永続性、非ブロッキングなマージ、履歴の内在化 を中核とし、リベースの過程でも既存の記録を破壊しない
- 約 470 行の Python コードで書かれたデモレベルの実装で、全コードと設計文書が パブリックドメイン として GitHub で公開されている
- Git の限界を超える マージ失敗のない次世代バージョン管理モデル を実験的に提示した事例
Manyana: バージョン管理の未来に向けた一貫したビジョン
- Manyana は Bram Cohen が公開した CRDT ベースのバージョン管理システムのプロトタイプで、既存システムのマージコンフリクト問題を解決しようとする試みである
- CRDT はマージが常に成功することを保証し、コンフリクトを情報的な表示として扱う ことで、ユーザーが実際の変更内容を明確に確認できるようにする
- このアプローチは 行順序の永続性、非ブロッキングなコンフリクト処理、構造内への履歴の内在化 という 3 つの中核的特性を持つ
- リベース(rebase) の過程でも既存の履歴を維持し、単一の共通祖先がない複雑なマージ構造も安定して処理できる
- Manyana は約 470 行の Python コードで書かれた デモ実装 であり、設計文書とコードは パブリックドメイン として GitHub で公開されている
CRDT ベースアプローチの核心
- CRDT は マージが常に成功 し、マージ順序に関係なく同じ結果を保証する eventual consistency を提供する
- 複数のユーザーが独立して作業したブランチをどの順序でマージしても、結果は同一に保たれる
- 行順序の永続性 により、同じ位置に挿入されたコードの順序は一度決まるとその後も維持される
- これにより、ブランチごとにコンフリクト区間の解決結果が異なってしまう問題を防げる
- コンフリクトは情報提供用の表示としてのみ扱われ、マージを妨げない
- マージ結果は常に生成され、コンフリクトは「近い位置で同時に変更された部分」として表示される
- 各変更の主体と内容を追跡することで、有用なコンフリクト表示 を提供する
- 履歴が構造の中に内在している
- ファイルの全行を含む 「weave」構造 で状態を表現し、各行に追加・削除時点のメタデータを含める
- マージ時には共通祖先を探したり DAG を探索したりすることなく、2 つの状態を入力すれば常に正しい結果が生成される
改善されたコンフリクト表示
- 既存のバージョン管理システムでは、コンフリクト時に単に 2 つのコードブロックを並べて表示するため、ユーザーが自分で差分を推測しなければならない
- Manyana は各コンフリクト区間を 「削除された」、「追加された」 などと明示し、誰がどの変更を行ったのか を表示する
- たとえば、あるユーザーが関数を削除し、別のユーザーがその関数内部に 1 行を追加した場合、Manyana は各変更の構造を明確に区別して見せる
- これによりユーザーは 2 つのブロックを比較する代わりに、変更の意味と文脈を即座に把握 できる
リベースの再定義
- CRDT ベースのシステムでは、リベースは 履歴を破壊しない
- 従来のリベースはコミットを新しいベースの上に積み直し、架空の履歴を生成する
- Manyana では同じ効果を得つつ、元の履歴をすべて維持 する
- そのためには DAG に 「主要祖先(primary ancestor)」 の注釈を追加するだけで十分である
- この方式は 共通祖先のないマージ構造 でも安定して動作し、従来の 3-way マージの失敗を避けられる
プロジェクトの現在の状態
- Manyana は 完全なバージョン管理システムではなくデモ実装 であり、個別ファイル単位で動作する
- 約 470 行の Python コード で構成されている
- Cherry-pick と ローカル undo 機能はまだ実装されていないが、README に今後の実装方針が示されている
- このプロジェクトは CRDT ベースのバージョン管理が UX の問題を解決できることを実証 しており、既存ツールより優れた結果を提供する
- 全コードは パブリックドメイン(public domain) で配布され、設計文書全体は GitHub README に含まれている
コミュニティ反応の要約
- あるユーザーは、Git は 10 年以上使われてきたが、新しいバージョン管理パラダイムが必要 だと評価し、Manyana の試みを好意的に言及している
- マージが常に成功するという概念は直感的ではないと指摘し、追加の例や説明 を求めている
- リベース改善のアイデアに関心を示し、個人プロジェクトでは 中間ブランチを通じたマージ管理方式 を使っていると述べている
- Git の限界として バイナリファイル処理、左右ブランチ区別の混乱、大規模コード変更の要約不足 などを指摘している
- 将来のバージョン管理では トークン単位認識(token-aware) 機能や 言語・ファイル形式別プラグイン をサポートするとよいと提案している
- 別のユーザーは、Manyana が Pijul や Darcs と似た基盤を持つのかを質問し、Darcs の性能問題や Pijul の現在の状況との比較を求めている
結論
- Manyana は CRDT をバージョン管理に適用した実用的なデモ であり、コンフリクト処理とリベースの問題を根本から再設計している
- マージ失敗のない構造、コンフリクトの情報化、履歴の構造的内在化は、既存の Git モデルの限界を超える設計の方向性 を示している
- 完全なシステムではないものの、次世代バージョン管理システムの設計青写真 として意味のある出発点である
1件のコメント
Hacker Newsの意見
merge の表示方法は、履歴の表現とは別問題だと思う
私も Git の標準 merge UI は嫌いなので p4merge を使っている。4つのパネル（左、右、共通ベース、結果）を表示するツールで、衝突の原因と解決方法を一目で確認できる
わざわざ VCS 自体を変える必要はないと思う
merge.conflictStyle設定を"diff3"や"zdiff3"に変えれば、ベース版まで表示されるこうすると衝突マーカーを見るだけで、どちらが 新しいコード を追加したのか推測できる
以前あるポッドキャストで、新しい VCS を作ったゲストが Git の diff の保存方式 を誤解しているのを聞いて驚いた。何年もプロジェクトを進めていても基本概念すら調べていないのを見ると、今でも NIH（再発明） の精神は健在だと感じる
ただし SCM レベルで処理すれば、ユーザーの merge 履歴を 記憶 できる利点がある。Git はこういう部分でエッジケースがある
merge が絶対に失敗しないことが良いことなのかは分からない
merge の失敗は単なる位置の衝突ではなく、意味的な衝突 を知らせるシグナルであることが多い。こういう場合は手動で処理すべきだ
CRDT はバージョン管理に向いていないと思う
衝突はバージョン管理の本質だ。2人の開発者が別々の方向にコードを変えたなら、結局は 意味的な選択 が必要になる。CRDT はこういう状況で 見当違いなコード を作る可能性が高い
Git の上でよりよい merge UX を提供するツールはすでに多くあり、cherry-pick や revert が容易なのも Git の利点だ
たとえば一方のブランチで定数を削除し、もう一方のブランチでその定数を使っていればコードは壊れる
Git の衝突は大半が構文的問題なので、より賢い semantic merge や CRDT アプローチが役立つ可能性はある
たとえばファイル名、属性、ハッシュなどを追跡する際に OR-set（https://en.wikipedia.org/wiki/…
ただし衝突解決は依然として外部インターフェースで処理する必要がある
なぜ CRDT に集中するのかよく分からない
衝突の意味的問題は依然として存在する。むしろ変更が 入り混じって（interleave） 見えるので、さらに混乱しそうだ
私は rebase 中心主義者 だ。merge commit は避けるべきで、すべての commit は独立した単位であるべきだ。Gitflow は アンチパターン だと思う
Jujutsu や Gerrit は、Git の本当の問題である「レビューのフィードバックに基づく commit チェーン管理」をうまく解決している
Git はスナップショットを再適用するので、同じ作業が二重に存在することになる。一方 Pijul は パッチ単位 で動作し、順序に関係なく同じ結果になる。これこそ本当に独立した作業単位だと思う
衝突がある状態でも特定の commit だけを 取り消し（undo） できる。Git より柔軟な構造を持てる
実際には最終結果だけが重要なことも多い。squash merge を適切に混ぜるのが現実的だ
しかし本質的に衝突が必要な問題もある。たとえば 同時編集で文字が混ざる現象 のように、むしろより悪い結果を招くこともある
このプロジェクトは Bram が以前作った Codeville のアイデアを発展させたもののようだ
Codeville は 2000年代初頭の DVCS ブームの時期に登場し、weave ベースの保存と merge を使っていた。CRDT より 10年早い概念だが、自然につながる発想だ
Bram が今もこの問題に取り組み、新しい試みを続けているのはうれしい
arxiv:2002.09511
「CRDT ベースの VCS はまだ存在しない」という言い方には同意できない
すでに Pijul が存在し、専門家たちが何千時間も投入したプロジェクトだ
6年間実験中で、4年前に自分で イシュー を上げたが、まだ反映されていない
Pijul は 自分自身で開発される VCS なので GitHub は使っていない
pijul pull -aをすると衝突が起きるので、そのまま再 clone している。追跡更新用の pull があるのか気になるmanana.py は 473行の 依存なしの Python コード だ
実装そのものは約240行で、残りはテストコードだ。シンプルだが印象的だ
JS エコシステムの left-pad 事件を思い出すと、Python にもこういう 小さくて責任あるパッケージ がもっと増えてほしいと思う
こういうシステムは、チーム規模ごとの merge 衝突の現れ方 を分析して設計すべきだ
1人、10人、100人、1000人のチームがそれぞれどんな問題を抱えるのか、そして エージェントベース開発 がそれをどう変えるかも考える必要がある
私の経験では、1〜100人規模ではチームごとにコードのサブツリーを分けるので衝突はほとんどない。
エージェントが増えれば 100人が 1000人のようになるかもしれないが、今のところは 実際の問題より先に解決策が出てきた感じ だ
最近は Codex に merge 衝突を任せれば終わり なので、わざわざ新しい VCS を使う理由は薄れている
Git は大規模チーム向けに設計されており、エージェント時代には プロセス自動化 で十分対応できる
問題はむしろ 共有ライブラリのボトルネック やアクセス制限ポリシーから生じる
衝突より大きな問題は Git のスケーラビリティ だ
リポジトリサイズと変更速度が限界に近づいており、サーバー、クライアント、プロトコル全体の再設計が必要だ
個人的には、このシステムが何の問題を解決するのかよく分からない
抽象的には面白いが、実際には jj のほうが Git よりずっと実用的だ
次の段階はファイル単位ではなく AST レベルでバージョン管理 するシステムだと思う。
LightTable や Dark のような試みもあったし、こういう ツリーベースの VCS を試してみるとよさそうだ