jj init – 开始认真考虑用 Jujutsu 替代 Git

原文 ↗ Hacker News 讨论 ↗

一个名为 Jujutsu（“jj”）的新版本控制工具，目标是在保持与现有 Git 仓库兼容的同时，替代 Git 面向用户的工作流。评论者对 jj 的模型很感兴趣：工作副本始终是一个提交、历史编辑和堆叠式更改的处理更简单，以及在大型或复杂工作流中可能带来的优势——但很多人也对失去 Git 的 index 心存疑虑，担心概念复杂性会增加，并质疑开发者是否应该直接去学习 Git 的底层模型。总体来看，人们认为 jj 在人体工学和工具体验上很有前景，但怀疑它是否能撼动 Git 的主导地位，或真正摆脱 Git 的底层复杂性。

Jujutsu（jj）的整体反响

  • 一些评论者对 jj 很感兴趣，计划试用，尤其是那些已经对 Git 的 UI 感到沮丧的人。
  • 几位已经切换的人表示一开始会有摩擦，主要是因为“工作副本就是一个提交”这一模型，但他们也说一旦“理解了”，Git 就会显得笨拙。
  • 其他人则持怀疑态度，认为 jj 只是把复杂性叠加在 Git 之上，并没有真正简化版本控制。

工作副本作为提交与缺少 index

  • jj 的模型是：所有更改始终都是某个提交的一部分；没有暴露出来的“index”或未暂存状态。
  • 支持者认为，这减少了概念状态，并让拆分提交之类的操作更容易、也更不容易出错。
  • 批评者更喜欢 Git 的两步式“add 然后 commit”，认为这样会鼓励有意识地把相关更改分组，也避免把所有内容都自动提交。
  • 关于 jj 是否真正保留了类似 index 的行为，存在一些困惑；有评论者澄清说，它实际上默认会把所有更改都提交。

提交拆分与工作流

  • jj 的 split 命令被大量讨论。
  • 支持者认为，与 Git 需要多步 rebase 相比，它极大降低了回过头来拆分提交、重组历史的摩擦。
  • 反对者觉得 jj split 的工作流不直观（例如哪一部分算“第一部分”还是“第二部分”），并认为拆分是太重要的功能，不该变得这么“怪”。

Git 的复杂性、心智模型与学习负担

  • 许多评论抱怨 Git 概念令人困惑（detached HEAD、reflog、rebase merge 语义、ours/theirs 反转），以及各种“踩坑点”出现得太频繁。
  • 另一些人则为 Git 辩护，认为它很强大，但只要真正掌握核心模型就并不算太难；他们主张开发者应该更深入地学习工具，类比于理解数据库或网络。
  • 关于“需要理解内部机制”是否适合日常使用，存在分歧。

工具、GUI 与大型仓库

  • 多位评论者强调优秀 GUI 的重要性（用于暂存、按块选择、bisect、reflog），并表示下一代 VCS 应该以 GUI 为先。
  • 有人指出 jj 目前缺少成熟的 GUI 支持，这削弱了那些高度依赖类似 index 的暂存体验的工作流。
  • 对于大型仓库，有人提到 watchman 可以改善 jj 的性能，但整体上，大型仓库方面的讨论仍然较少，而且有些不够明确。

元话题：命名、生态与长期性

  • 有人担心二进制名 jj 会和常见的 Vim 键位冲突。
  • 一些人担心 jj 因与 Google 资助的工作相关而缺乏长期可持续性，另一些人则澄清它并不是 Git 的分支，只是使用 libgit。
  • 还有少数人认为，最需要的不是一个新的 VCS，而是一个更合理、兼容 Git 的接口或前端。