Gitに代わる分散バージョン管理システム
Gitが事実上の標準となった後も、Gitの体験（UI/UX）やスケーラビリティに課題意識を持ち、別のアプローチを取る分散バージョン管理システム(VCS)がいくつか登場・並存している。このノートでは、これまで調べた個別のVCSをまとめる。
Git互換レイヤー系
Gitのデータモデル（.gitディレクトリ）自体はそのまま使いつつ、その上のUI/UXだけを作り直すアプローチ。
- Jujutsu (jj) — Googleのエンジニアが開発。Gitと同じ
.gitディレクトリを読み書きしつつ、ワーキングコピー自体をコミットとして扱う、コンフリクトをファーストクラスのオブジェクトにする、操作ログによる完全なundoなど、UI/UXを大きく作り直している。 - Sapling — Metaが開発・社内利用。CLI(
sl)はもともとMercurialをベースにしており、スタック型コミット・Smartlog(Interactive Smartlog)といったMercurial由来のワークフローをGit互換の形で提供する。
両者とも「Gitのエコシステム（GitHub・CI・チームメンバーのgitコマンド）はそのまま使いたいが、日々の操作体験は変えたい」という動機は共通する。
Git以前から存在する独立系
- Mercurial — Matt Mackallが2005年に開発。GitとほぼGitと同時期(13日後)に発表された分散VCSで、当初から使いやすいCLIを志向していた点がGitとの対比でよく語られる。MozillaやPythonといった大規模プロジェクトで採用された実績があるが、VCS市場シェアではGitに大きく水をあけられている。
JujutsuもSaplingも、設計思想の一部をこのMercurialから受け継いでいる。スタック型コミット・revset・匿名ブランチといった概念は、いずれもMercurial起源かMercurialのエコシステム(hg-evolve拡張など)で先に実践されていたものが、Git互換の新しいツールに引き継がれる形で再登場している。
パッチ理論系
コミット（ツリーの状態）ではなく「パッチ（変更そのもの）」を基本単位に据える、上記とは異質な系統。
- Darcs — David RoundyがHaskellで開発。パッチをファーストクラスの概念として扱う「パッチ代数」に基づく分散VCS。マージがコンフリクトのサイズに対して指数時間かかる場合があるという弱点を長らく抱えていた。
- Pijul — Rust製。Darcsのアイデアを引き継ぎつつ、より健全な数学的パッチ理論に基づいて再設計し、指数時間マージ問題を解消している。
Jujutsuの「コンフリクトをファーストクラスのオブジェクトとして扱う」という設計は、この系統の発想を部分的に取り入れたものとされている。
対応ツール
diffビューアのhunkはGit/Jujutsu/Saplingの3つに対応しており、jj・Sapling環境では自動検出してネイティブのrevsetを使う。こうした周辺ツールの対応状況からも、Git互換VCSとして一定の認知が進んでいることがうかがえる。