我差不多是把 Mozilla 上的 Mercurial 给“搞没了”

原文 ↗ Hacker News 讨论 ↗

Mozilla 从 Mercurial 迁移到 Git 和 GitHub，被视为更大趋势的一部分：尽管 Mercurial 具有更友好的 CLI 和扎实的功能，但在 Git 的网络效应、工具生态，以及 Microsoft、Meta 和 Google 等巨头的支持下逐渐被边缘化。评论者回顾了像 Bitbucket 这样的早期 Mercurial 托管平台为何放弃它，讨论了大型公司如今如何围绕 Git 式模型构建自定义系统（Sapling、jj、Perforce、Piper），以及为什么许多开发者仍觉得 Git 的 UX 比 Mercurial 更难用。这个讨论串还权衡了 GitHub 薄弱的代码评审体验，以及 Mozilla 依赖微软旗下平台所带来的锁定风险，与其对齐开源协作主流基础设施所带来的现实收益之间的取舍。

Mercurial 的衰落与网络效应

  • 许多人认为 Mercurial 实际上已经“结束”了：Bitbucket 放弃了 hg，主要托管平台都只支持 Git，新的 Mercurial 采用量极少。
  • 也有人反驳说 Mercurial 仍在维护，支持 Python 3，包含 Rust 组件，并且还在获得诸如 Changeset Evolution 之类的功能。
  • 形成的共识是：Git 之所以胜出，主要是因为网络效应（Linux 内核、GitHub、工具生态）。一旦人们学会了 Git，即便 hg 更顺手，改用别的工具也显得收益很低。

托管平台与缺失的“HgHub”

  • Bitbucket 经常被提及为事实上的“hghub”，它先是只支持 hg，后来加入 Git，最后又移除了 hg。
  • 有人认为移除 Mercurial 很短视；也有人认为 hg 的使用量已经跌到新用户的 1% 以下，同时维护两套 VCS 系统不值得。
  • SourceHut 和 Heptapod 被提到是仍然对 Mercurial 友好的托管平台。

大公司的 VCS 技术栈（Meta、Google、Microsoft）

  • Meta 历史上大规模使用 Mercurial；如今对外提供 Sapling，这是一个源自 Mercurial、并兼容 Git 的系统。内部人们仍然使用 hg 风格的命令，但开源的 Sapling 已经分化得更像一套独立的 VCS。
  • Sapling 的 Git 互操作性被认为很有用，但仍然比较粗糙（LFS 问题、强推带来的摩擦、大仓库边缘案例）。
  • Google 用一个基于 Mercurial 的客户端来前置其 monorepo（Piper），因为 hg 有真正的 wire protocol；目前正在推进用 jj（Jujutsu）替换它，jj 借鉴了 hg 的交互体验，同时与 Git 存储互操作。
  • Microsoft 投入大量资源让 Git 能在超大仓库和部分克隆场景下扩展。

Git 与 Mercurial 的 UX 和理念

  • 许多人称赞 hg 的 CLI 更干净、术语更一致、Windows GUI 更好（例如 TortoiseHg），以及 revsets 和 phases 这类功能。
  • 也有很多人批评 Git 的命令令人困惑、危险参数很多，以及一些反直觉的概念（index/staging area、stash、reset --hard）。
  • 反方观点是：很多所谓的“难用”其实来自对分布式 VCS 概念的学习，而不是 Git 本身；一旦理解之后，Git 很强大，而且真的很难把数据弄丢（reflog 等）。
  • 历史上的分歧在于：Git 很早就接受了历史重写；Mercurial 在理念上对此更谨慎，导致了 MQ 之类的工具，后来又演化出更复杂的模型（phases、evolve）。

代码评审工作流与 GitHub UI

  • 对 GitHub PR 评审在严肃或 stacked 工作流中的表现批评很强：对多个版本的处理很差，rebase 后上下文丢失，range-diff 支持薄弱，对未变更行的评论有限，多轮评审也很别扭。
  • Gerrit 和 Phabricator 这类系统因其按提交/stacked diff 的工作方式，以及在补丁版本之间清晰呈现演进而受到称赞。
  • Graphite、CodeApprove、Reviewable 等第三方工具试图在 GitHub 之上叠加更好的评审和 stacked-diff 工作流。

大仓库、monorepo 与二进制文件

  • Git 在 monorepo 方面的故事被认为历史上很弱（submodules、sparse checkout、partial clone 都来得很晚）。有人认为如果没有大量工具支持，Git 并不适合 Google 风格的 monorepo。
  • 也有人坚持认为，Git 对于低于“Google 规模”的大型仓库完全足够，而 monorepo 暴露的更多是流程和组织问题。
  • 游戏和 ASIC 开发据说依赖 Perforce 来处理大型二进制文件；Git LFS 得到了广泛支持，但相比 Mercurial 的 largefile 处理，被认为笨重且工作流负担更大。

替代方案与未来方向

  • 一些人喜欢 Fossil 的一体化方案（VCS + issue tracker + web UI）以及单二进制部署。
  • Pijul 被提到是一种先进的基于 patch 的 VCS，有人希望它将来会更常见。
  • Jujutsu 被强调为一个很有前景、兼容 Git 的 VCS，带有操作日志和内建撤销，目标是在 Git 和 Mercurial 之外进一步现代化 VCS 体验。

Mozilla 转向 Git/GitHub

  • 许多人认为 Mozilla 转向 Git 是务实之举，因为生态现实以及内部对 Git 工具的依赖（例如用 git-cinnabar 作为桥梁）。
  • 也有人认为选择 GitHub 本身就与 Mozilla 所宣称的去中心化价值观相冲突，并让贡献依赖于一个由 Microsoft 控制的账号。