Pijul 是一个自由且开源（GPL2）的分布式版本控制系统

原文 ↗ Hacker News 讨论 ↗

Pijul 是一个用 Rust 编写、基于补丁的分布式版本控制系统，被描述为一种在理论上比 Git 更完善的替代方案，承诺带来更好的合并行为、一等冲突处理、更容易的 cherry-pick，以及对大型或部分仓库更高效的支持。评论者对其偏数学化的设计以及可交换补丁、部分克隆等特性很感兴趣，但也指出对许多用户来说，日常工作流与 Git 并没有太大差别，而且仍然需要清晰、具体的真实世界优势示例。当前识别出的主要障碍是生态和工具成熟度——托管、IDE 集成、CI、文档以及从 Git 迁移的路径——再加上 GitHub 中心化工作流带来的惯性。

整体情绪

  • 许多人觉得 Pijul 在概念上很令人兴奋，也很“扎实”，尤其是它的理论基础和基于补丁的模型。
  • 也有人怀疑，它的优势是否大到足以让人从 Git 占主导地位的生态中迁移出去。

Pijul vs Git：模型与宣称的优势

  • 基于补丁，而不是基于快照：补丁有身份，并且在彼此独立时可以交换顺序（commute）。
  • 这带来了：
    • “真正的” cherry-pick：跨分支保持同一个补丁 ID；避免重复提交以及相关的合并痛点。
    • 更少且更正确的合并：某些复杂的三方合并能自动解决，而 Git 需要人工处理；冲突被表示为一等数据，且已做出的解决不会再次出现。
    • 内容等价的历史：生成同一棵树的不同补丁顺序会被视为同一个状态。
    • 部分/单仓库（monorepo）工作流：可以只处理补丁/文件的子集，而不需要子模块或类似 LFS 的变通方案。
    • 通过将操作与内容分离，更好地处理大型/二进制文件。

实际工作流与示例

  • 讨论了以下场景中的好处：
    • 维护多个长期发布版本，并将同一个 bugfix 补丁应用到所有版本上。
    • 长期存在的下游分支持续与上游合并。
    • 像内核这类大量依赖补丁、补丁在不同树之间流转的项目。
  • 也有人认为 Git 现有工作流（推送前 pull/merge/rebase、CI、rerere，以及 Jujutsu 之类的工具）已经“足够好”，并且更偏好 Git 的推送拒绝行为以保证安全。

工具、托管与生态

  • The Nest（Pijul 的“hub”）和编辑器集成已经存在（例如 VS Code 插件、仍在进行中的 Emacs 支持），但：
    • The Nest 的源码尚未公开。
    • Web UI 被认为比较有限（diff 视图、标签、链接）。
  • 人们反复要求 Git 兼容性以及类似 GitHub 的托管/CI；缺乏强大的生态被视为主要障碍。

采用障碍与 UX / 叙事

  • 文档和网站被批评“卖点”不足：对初学者来说，Git、channels 与 branches 以及版本/标签工作流之间的具体优势解释不够清晰。
  • 有人反馈 UX 比较粗糙（例如缺少或不明显的 git status 对应命令），不过核心命令是存在的。
  • 名称和发音也有人讨论，但与生态/工具问题相比只是小问题。

语义、冲突与 CI

  • 线程澄清：Pijul 和 Git 一样，只处理文本结构，而不理解程序语义；合并后仍然可能得到语义上有问题的代码。
  • CI 和基于测试的验证仍然是必须的；Pijul 不是 CI 系统。