本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

An outsider’s perspective on Scion and Mononoke

最近，Anthropic 发布了一篇关于其新型集中式版本控制系统 Scion 的博文。作为 Databricks 源代码控制团队的一员，我们拥有一个庞大的单体仓库（monorepo）并正在探索各种方案，因此我认为分享一下我的观点可能会有所帮助。（免责声明：本文仅代表我个人观点，不代表雇主立场。）我建议在阅读本文之前先阅读 Anthropic 的文章。你可能还需要预读 Rain Paharia 的《Anthropic 的 Scion 在很大程度上受到了 Mononoke 的启发》以及后续文章《关于 Anthropic 的 Scion 抄袭 Mononoke 的更多信息》。

My history with version control

Before we get into the weeds, it might be helpful to you to know where I’m coming from. If you’re not interested in this, you can jump to the Technical Commentary section. I have never worked at Facebook, but one of my all-time favorite tech talks is Durham Goode’s Scaling Mercurial at Facebook from Git Merge 2017. Goode was the longest-serving and most senior member on Facebook’s Source Control team. The talk covers various interesting aspects for both the server side and the client side.

我与版本控制的历史

在深入细节之前，了解我的背景可能会对你有所帮助。如果你对此不感兴趣，可以直接跳到“技术评论”部分。我从未在 Facebook 工作过，但我最喜欢的技术讲座之一是 Durham Goode 在 Git Merge 2017 上发表的《Scaling Mercurial at Facebook》。Goode 是 Facebook 源代码控制团队任职时间最长、资历最深的成员。该讲座涵盖了服务器端和客户端的多个有趣方面。

For the server side, some of the topics include solving push contention with server-side rebasing (pushrebase), using scalable object storage for commits, moving various source control queries to the server, etc. For the client, there’s mention of the smartlog and other CLI commands for easier manipulation of history (compared to rebasing in Git). However, more so than the technical aspects of the talk (which are interesting in their own right!), the main thing that has stayed with me throughout these years is the deep care for users that is reflected in Goode’s tone and words.

在服务器端，一些主题包括通过服务器端变基（pushrebase）解决推送冲突、使用可扩展的对象存储来处理提交，以及将各种源代码控制查询迁移到服务器等。在客户端，讲座提到了 smartlog 和其他用于更轻松操作历史记录的 CLI 命令（与 Git 中的变基相比）。然而，比起讲座中的技术层面（它们本身就很有趣！），这些年来最让我印象深刻的是 Goode 的语气和言辞中所体现出的对用户的深切关怀。

It’s a bit difficult to convey this without the power of voice, you should watch the presentation! but here are some quotes which reflect this: In the context of hg smartlog: hg smartlog gives you a focused view of your branches and how they relate to the development trunk. I know Git can produce this kind of UI if you know the incantation, but the critical thing here is not that it can be done; it’s that it becomes the default view of their source-control environment. That is where the power comes from: making it really intuitive for users to use source control and understand the concepts without reading a man page.

如果没有声音的感染力，很难传达这一点，你应该去看看那个演讲！但以下是一些反映这一点的引语：在 hg smartlog 的背景下：hg smartlog 为你提供了分支及其与开发主干关系的聚焦视图。我知道如果你掌握了咒语，Git 也能生成这种 UI，但关键不在于它能否做到，而在于它成为了其源代码控制环境的默认视图。这就是力量的来源：让用户无需阅读手册页就能直观地使用源代码控制并理解相关概念。

In the context of hg absorb: hg absorb auto-magically identifies the right commits in a stack to squash fixes into and rewrites history accordingly. This makes it easier to work with stacked changes. This is the type of UI that we need to be inventing for our users: ones that match their intent and do it to the best of their ability, without making the user understand everything they have to do. It’s a little bit magic, but it’s magic in a very clean way. I think a lot of user experiences could benefit from this approach.

在 hg absorb 的背景下：hg absorb 会自动识别堆栈中合适的提交，将修复内容压缩进去并相应地重写历史。这使得处理堆叠式变更变得更加容易。这就是我们需要为用户发明的 UI 类型：能够匹配用户意图并尽其所能完成任务，而无需用户理解所有底层操作。这有点像魔法，但这种魔法非常简洁。我认为许多用户体验都可以从这种方法中受益。

On recovering from mistakes: If you want to undo an amend or undo parts of a commit in Mercurial, you just run unamend and uncommit. You don’t have to understand a reflog; you don’t have to get a PhD to understand reset anymore. It just works, and it gives users confidence that they can recover from mistakes. That’s one of the most important things we can do: provide user experiences that give them confidence in what they’re doing.

关于从错误中恢复：如果你想在 Mercurial 中撤销一次 amend 或撤销提交的部分内容，只需运行 unamend 和 uncommit。你不需要理解 reflog，也不需要获得博士学位才能理解 reset。它就是能用，并且让用户有信心从错误中恢复。这是我们能做的最重要的事情之一：提供让用户对自己的操作充满信心的用户体验。

Near the end, summing things up: On the user experience side, we as a source control community need to do a better job of building UIs that are accessible, intuitive, and that enable novice users to be power users. Everything I just talked about is how we are trying to do that for our users at Facebook. If the Git community could do that, the massive number of Git users taking advantage of it has the potential to redefine productivity for an entire generation of users.

在结尾总结时：在用户体验方面，我们作为源代码控制社区，需要更好地构建易于访问、直观且能让新手用户成为高级用户的 UI。我刚才所谈论的一切，就是我们在 Facebook 为用户所做的努力。如果 Git 社区也能做到这一点，那么庞大的 Git 用户群体就有潜力为整整一代用户重新定义生产力。

Over the years, the possibility of these workflows lingered in my mind as I continued working with Git. I tried building my own wrappers on top of the git CLI to do some of these things, but I couldn’t get the performance to be reasonable since everything shelled out to git all the time, and I didn’t understand Git’s internals well enough to do something better. I ended up sticking with vanilla Git until Waleed Khan created git-branchless, with support for a smartlog, in-memory rebases, undo and more. I eagerly adopted it.

多年来，当我继续使用 Git 时，这些工作流的可能性一直萦绕在我的脑海中。我尝试在 git CLI 之上构建自己的包装器来实现其中一些功能，但由于所有操作都不断调用 git，我无法获得合理的性能，而且我对 Git 的内部原理了解不够，无法做得更好。最终我还是坚持使用原生 Git，直到 Waleed Khan 创建了 git-branchless，它支持 smartlog、内存变基、撤销等功能。我迫不及待地采用了它。

I also used Stephen Jung’s git-absorb quite a bit. Even today, the initial bit of git absorb’s README cites the mention of hg absorb on a Mozilla mailing list as the key inspiration. Finally, earlier this year (2026), I mostly switched to using jj, after having bounced off of it a couple of times. jj was created by Martin von Zweigbergk, who previously contributed to Git and later joined Google and worked on their internal Mercurial client for the monorepo. So even though I have almost exclusively worked with Git throughout my career, I am in a way indebted to the work on Mercurial by Goode and numerous other contributors.

我也经常使用 Stephen Jung 的 git-absorb。即使在今天，git-absorb 的 README 开头仍引用了 Mozilla 邮件列表上关于 hg absorb 的提及作为其核心灵感来源。最后，在今年早些时候（2026 年），在尝试了几次并放弃后，我基本转向了使用 jj。jj 由 Martin von Zweigbergk 创建，他曾为 Git 做出过贡献，后来加入 Google 并致力于其单体仓库的内部 Mercurial 客户端开发。因此，尽管我的职业生涯几乎完全是在使用 Git，但在某种程度上，我还是得益于 Goode 和其他众多贡献者在 Mercurial 方面的工作。

I’ve talked a bit about my personal usage of version control tooling. Let me briefly describe work I’ve done related to version control. From late 2021 to late 2025, I worked at Sourcegraph on code indexing and navigation. For the last two of those years, I worked more on the backend written in Go, where the code navigation was coupled to version control. During this time, one of the recurring sources of incidents was the (non-)incremental updates for the commit graph structure that was mirrored into Postgres, in order to be able to efficiently compute what code navigation data (stored in Postgres) was “visible” at which commit. I recall being frustrated with that, and half-jokingly proposing that it would be good to move to a more custom storage solution or have custom indexes next to Git’s storage.

我已经谈了一些我个人对版本控制工具的使用情况。让我简要描述一下我所做过的与版本控制相关的工作。从 2021 年底到 2025 年底，我在 Sourcegraph 从事代码索引和导航工作。在最后两年里，我更多地参与了用 Go 编写的后端工作，其中的代码导航与版本控制是耦合的。在此期间，事故的反复来源之一是镜像到 Postgres 中的提交图结构的（非）增量更新，这是为了能够高效计算哪些代码导航数据（存储在 Postgres 中）在哪个提交中是“可见”的。我记得当时对此感到很沮丧，并半开玩笑地提议，如果能转向更定制化的存储解决方案，或者在 Git 存储之外拥有自定义索引会更好。