编程与软件工程engineering.fb.com
Sapling：兼容 Git 客户端的新源码控制系统
Sapling: A new source control system with Git-compatible client
2022 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Meta（Facebook）开源了 Sapling，这是他们内部使用多年、为超大规模单体仓库（monorepo）打造的版本控制系统，同时提供一个 Git 兼容的客户端，因此可以直接操作 Git 仓库。文章介绍了它的可扩展性设计、与 Mercurial 的历史渊源，以及它能简化哪些 Git 里繁琐的操作（如 uncommit、unamend）。
为什么经久不衰：它把解决巨型 monorepo 规模问题的工业级工具公开出来，并给出一个可能改善 Git 命令行体验的替代客户端，是版本控制领域少见的、来自超大规模实践的新思路。
HN 评论精选
Facebook 一贯先私下分叉开源项目、再以自研成果回归；作者不认同当初导致分叉的做法，但欢迎打破 Git 垄断。
这篇评论来自一位 Mercurial 开发者：Facebook 曾参与 Mercurial 社区，但坚持按自己的方式行事，要求项目采用 Phabricator，并逐步用节点哈希取代顺序版本号，理由是他们的巨型仓库让顺序版本号变得无用。分歧最终太大，Facebook 不再公开谈论 Mercurial；几年后他们果然带着自己的分支回归，就像 HipHop VM、Hive 那样。这位评论者说自己大概不会转用 Sapling，但乐见有人冲击 Git 一家独大的局面，希望版本控制不止于 Git。
jordigh查看英文原文
Ah, there it is. I was wondering when this would happen. Facebook used to be involved with the Mercurial community, but it was difficult to work with them. They always wanted to do things their way, had their own intentions, and started to demand that the Mercurial project work the way that Facebook wanted. For example, they demanded that we start using Phabricator and started slowly removing sequential revisions from Mercurial in favour of always using node hashes everywhere, arguing that for their gigantic repos, sequential revisions were so big as to be useless. Eventually the disagreements were too great, and Facebook just stopped publicly talking about Mercurial. I figured they would emerge a few years later with their fork of it. They love doing this. HipHop VM for PHP, Apache Hive, MyRock; these are examples of Facebook forking off their development in private and then later emerging with some thing they built on top of it. The Mercurial project is surprisingly still chugging along, and there are still those of us who actually use Mercurial. I doubt I'll switch over to Sapling, because I disagreed with the things that made Facebook fork off in the first place. But if others like Sapling and this manages to put the slightest dent into the git monoculture, I'm happy for the change and innovation. I really hope that git is not the final word in version control. I want to see more ideas be spread and that people can see that there can be a world beyond git.
终于有人有实力重做 Git 的命令行体验，简单的撤销提交、撤销修改命令就足以说明 Git CLI 有多难用。
谢天谢地。我等了十年，盼着有规模和影响力的人做出更好的 Git 命令行，因为学一套没人会用的新流程没什么意义。这个看起来很棒：一条命令就能 uncommit 或 unamend，更让人意识到 Git 的 CLI 有多糟糕。
stevage查看英文原文
Thank god. I have been waiting ten years (https://www.google.com/url?q=https://stevebennett.me/2012/02/24/10-things-i-hate-about-git) for someone to develop a better CLI for git, someone with the scale and clout to do it well and gain mindshare. It's not that useful to learn a new workflow if no one you ever work with will be familiar with it. This looks incredible. A simple command to uncommit or unamend makes you further realise what a disaster the Git CLI is.
Meta 持续开源自己的 monorepo 解决方案很难得，即便多数人用不上也值得参考。
我算不上喜欢 Facebook 这家公司，但他们的开源工作相当可观。其他大公司也有巨型 monorepo、也要不断让新开发者上手的问题，但我想不出还有谁像 FB 这样持续把自己的解决方案公开出来。大多数人学会 Git、只处理中小型代码库（比如我）就够用了，但我仍很高兴 Sapling 存在，将来真遇到它解决的问题时可以用或借鉴。
fhd2查看英文原文
Not a big fan of FB as a company, but I think their open source work is pretty impressive. Various other large companies have the problem of giant monorepos that they constantly need to onboard new developers to, but I can't think of anyone other than FB who consistently released their solutions. Sure, most people are probably fine with Git once they learned it and if they only work with small to mid sized code bases (like me). But I'm still happy Sapling is out there, I might use it or learn from it if I ever run into the problems it solves.
肯定 Meta 把内部工具对外开放，同时关注它在公司外部是否真能独立使用。
关于 monorepo 之争，通常的对话是：“大型 monorepo 太难扩展了！”“Google 就做得很好啊！”“可我用不上 Google 的工具！”所以要感谢 Meta 既解决了问题又对外开放。有意思的是它在 Meta 之外好不好用——比如 Netflix 开源了很多工具，但不整套一起跑基本用不起来；Meta 目前在这方面做得不错，希望保持。
jedberg查看英文原文
In the argument of monorepo vs not, the usual argument goes like this: - It's too hard to scale for a large monorepo! - Google does it just fine! - But I don't have access to Google's tools! So kudos to Meta for both solving the problem and making it available to others. It will be interesting to see how useable it is outside of Meta. I know for example that while Netflix open sourced a lot of tools, most of them weren't useable unless you ran all of them together. So far Meta has been good at avoiding that, so hopefully that remains the case.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选