Pijul，名字是墨西哥语，j 发 h 的音，沟嘴犀鹃，一种共同筑巢的杜鹃鸟。

Pijul 对比 Git 的优势

1. 跟 Git 生成快照不同，Pijul 生成的是补丁（patch），保存的是差异，并且支持二进制文件，节省空间。
2. Git 用的 3-way-diff 算法在合并的时候是有多种“最佳结果”的，即使没有冲突，同样的输入，可以有不同的输出。在实践中，这里可能造成的 bug 都在 code review 时被人工修复了。而 Pijul 合并的结果是确定唯一的，合并完全不需要 code review。详见下文“什么是正确的合并”。
3. Pijul 的补丁满足交换律，补丁的顺序对结果没有影响，不会生成不同的 Hash 索引，这也是符合直觉的。
4. Git 在 cherry-pick 时相当于一份新提交，而在 Pijul 里 cherry-pick 的是同一份 patch。
5. 综合上面的特性，在 Pijul 里 rebase 也是安全的。如果你在 Git 里把 A-B-C 的 B rebase 到 D，你在各种教程里看到的结果都是 D-B1-C1，如果你再变回去就成了 A-B2-C2，B B1 B2 的内容一模一样，却有不同的 Hash ID，都存在你的仓库里。在 Pijul 里 rebase 后是 D-B-C，变回去还是 A-B-C。
6. Pijul 用非对称密钥做身份识别，可以更新历史里自己的身份信息（比如邮箱地址）而不影响代码历史。

Pijul 对比 Git 的劣势

1. 没有生态。开发者好像是个数学家，理论完美，也做了类似 Github 的 https://nest.pijul.com/，单用 cli 工具很好用，但生态还是太匮乏了，目前 VS Code 的插件都需要自己编译，更不用说 GUI 工具以及整合其他工作流了。

其他特点

1. 理论上可以像 Git 一样 GC，删除 dangling patch，但是目前应该是没有实现类似功能。

什么是正确的合并

有一个文件，只包含两行，第一行一个字母 A，第二行一个字母 B。

A
B

两个人同时在本地工作区编辑这个文件。

第一个人在原始内容上面增加一个字母 G 并提交：

G
A
B

然后又增加字母 A B 并提交：

A
B
G
A
B

第二个人在原始内容中间增加字母 X 并提交：

A
X
B

现在合并两个人的“工作成果”，Git、SVN、Mercurial 等版本管理工具会生成下面左边的结果，Pijul 的是右边：

A  A
X  B
B  G
G  A
A  X
B  B

Git SVN hg	Pijul

需要说明的是这里不存在冲突，因为两个人都没有修改原始的 A B。造成左图的原因是三路差异算法不能识别出绿色的 A B 是后加的，不是原始的 A B。