cloudparts

Sapling

Meta’s source control system, grown out of Mercurial: an open-source sl client that works with Git repositories and makes stacks of commits and undo easy, plus a server and virtual filesystem that scale it to Meta’s monorepo.

What it is
Version control
Type
Open source
Made by
Meta
License
GPLv2 (MIT for the website and the ISL web UI)
Facts checked
20 October 2026
Website Source code

What it is

Sapling is the source control client Meta uses for its monorepo, open-sourced in November 2022. It started as an extension to Mercurial and grew into a system of its own, and its sl command still shares much of Mercurial’s interface. Like Git it is distributed and uses hash-addressed commits, but each command does one thing: there is no staging area, local branch names (called bookmarks) are optional, and running sl with no arguments prints the smartlog, a graph of your own commits and the important remote branches, with the thousands of irrelevant commits on main hidden. Commits form stacks: you sl goto a commit in the middle, sl amend it, and Sapling rebases the commits above it, tracking each commit’s mutation history so the stack can be rebuilt later. sl undo, sl uncommit, sl unamend and sl hide reverse common mistakes.

The full system has three parts. The client builds and runs on Linux, macOS and Windows, clones and works with ordinary Git repositories, and can submit a stack of commits to GitHub as pull requests with sl pr submit; sl web opens the same smartlog as an interactive web UI. Mononoke, a distributed server written mostly in Rust, and EdenFS, a virtual filesystem that fills in working-copy files only when they are read, run in production at Meta. Their code is in the same repository, but Meta doesn’t yet support either outside the company. With them, Sapling serves a repository with tens of millions of files, commits and branches.

The goal is that every operation scales with the files a developer uses, not with the size of the repository. A clone downloads almost no history: Segmented Changelog fetches the shape of the commit graph in a few megabytes and fills in commits on demand, so smartlog takes under a second however big the repository is, and log and blame bisect the graph in O(log n) time, even on Git repositories. Without EdenFS, Watchman tells sl status which files changed, and teams can commit shared “sparse profiles” listing which parts of the repository to check out. Many scale features need Meta’s server, so they don’t apply to Git repositories. The latest release is 0.2.20260929 (September 29, 2026).

Why teams pick it

  • Stacks of small commits are first-class: edit any commit in place and the rest restack automatically, and sl absorb moves pending edits into the right commit
  • Easy to recover from mistakes: undo, redo, uncommit, unamend, hide and an interactive undo -i that scrolls back through old smartlog views
  • Works with existing Git repositories and GitHub, so one developer can try it without the team switching
  • Built to scale with the files you use: lazy history, shared sparse profiles and, with Meta’s server and EdenFS, repositories of tens of millions of files

Watch out for

  • The biggest scale features need Mononoke and EdenFS, which Meta doesn’t yet support outside the company
  • Git support has gaps: submodules aren’t fully supported, Git LFS only partly, and mixing sl and git commands in one repository might not always work
  • Stacks submitted with sl pr show up as overlapping pull requests that can confuse reviewers using GitHub’s own UI
  • Fetching history and branches on demand saves downloads at the cost of needing to be online more often than with Git

Alternatives

What all version control have in common →Compare side by side →
GitOpen sourceThe distributed version control system almost everyone uses: every clone holds the full history, stored as objects named by the hash of their content.+1 Git LFSMercurialOpen sourceA distributed version control system from the same month as Git, written mostly in Python, with a smaller command set, append-only storage and “phases” that stop you rewriting history others already have.JujutsuExperimentalOpen sourceA Git-compatible version control system, run as jj, where the working copy is itself a commit, every operation can be undone, and conflicts are stored in commits instead of stopping you.FossilOpen sourceA distributed version control system from the author of SQLite that keeps a whole project (code, tickets, wiki, forum and chat) in one SQLite database file, served by one small executable with its own web interface.PijulBetaOpen sourceA distributed version control system that stores changes instead of snapshots, built on a mathematical theory of patches: independent changes apply in any order with the same result, and a conflict, once resolved, stays resolved.

How it fits with other technologies

Try Sapling on a Git repository · bash

sl clone https://github.com/facebook/sapling
cd sapling
sl                                  # the smartlog: your commits, where you are, main

sl commit -m 'my first commit with Sapling'
sl goto COMMIT                      # move to a commit in the middle of your stack
sl amend                            # change it; the commits above are rebased
sl absorb                           # fold pending edits into the commits they belong to
sl undo                             # take back the last operation

sl pr submit                        # one GitHub pull request per commit in the stack
sl web                              # the interactive smartlog in a browser

The three parts of Sapling#

Only the client is supported outside Meta; the server and filesystem are buildable from the same repository for unsupported experiments.

Sapling client

open source

The sl command line and the Interactive Smartlog web UI, also built into VS Code. It works with Git repositories in two modes: .git mode keeps Git’s file formats so git commands still work, and .sl mode gives up git commands for more of Sapling’s scale features.

Mononoke

the server

A distributed server written mostly in Rust, meant to accept thousands of commits an hour across millions of files. Its open-source build can store data in MySQL, SQLite, files or S3. With it, sl push lets the server rebase your commits onto the branch, so many pushes can succeed at once.

EdenFS

virtual filesystem

Makes a checkout look like the whole repository but fetches each file the first time it is read. Checkouts become fast, at the cost of a small delay on first access to a file.

See it in a real stack

No architecture uses Sapling yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2012–2026

Around 2012 Facebook projected its repository’s growth a few years ahead and saw that its setup, a Subversion server with a Git mirror, would soon become a bottleneck. By early 2014 the main repository took thousands of commits a week across hundreds of thousands of files. Splitting it would have made large atomic refactorings harder, and its engineers knew Git, but after much deliberation the team concluded that Git’s internals would be difficult to work with for an ambitious scaling project. It chose Mercurial, written mostly in clean, modular Python and easy to extend, and contributed over 500 patches to it in a year and a half.

That early work set Sapling’s shape. Integration with Watchman, Facebook’s file monitor, let status find changed files without scanning them all, making it more than five times faster than Git’s status on that repository. The remotefilelog extension made clone and pull download only commit metadata and fetch file contents on demand through Facebook’s memcache, making them 10 times faster. What began as a Mercurial extension grew into a system of its own, with new storage formats, wire protocols and algorithms, and a new server, Mononoke, whose early code Meta published in 2017.

On November 15, 2022, after 10 years of work, Meta open-sourced the client as Sapling, with built-in Git support so anyone could try it on their existing repositories, alongside ReviewStack, a demonstration review UI for stacked GitHub pull requests. It said it hoped to open-source the server and virtual filesystem later; their code now sits in the same repository, still unsupported outside Meta. In October 2026 Anthropic named Mononoke and its Bonsai data model as prior art for Scion, its own version control system.

Why it’s built this way

Make Mercurial scale instead of splitting the repository
One repository made large, atomic changes across the codebase easy, and the team didn’t want source control limits to dictate code structure. Mercurial’s modular Python was easier to extend than Git’s internals, and its community reviewed the patches with Facebook’s scale in mind.
Fetch history and files lazily
With thousands of commits a day, downloading all history to every client was slow. Fetching metadata first and contents on demand sits between a centralized system’s speed and a distributed one’s robustness, at the cost of needing a reliable server and network.
Make stacks and undo first-class
Meta engineers ship features as stacks of small, individually reviewed commits, which in Git takes complex commands such as git rebase -i. The Sapling team was small and had to support tens of thousands of developers, so people needed to be able to fix their own mistakes.
Release the client first, speaking Git
Meta called the client the first step in a longer process of releasing the whole system. Built-in Git support let anyone use it on repositories they already had, without a Sapling server, even though some scale optimizations don’t apply to Git.

Timeline

  1. 2012

    Work begins on scaling Facebook’s monorepo, as an extension to Mercurial

  2. 2014

    Facebook describes its Mercurial work: Watchman, remotefilelog and over 500 patches (January 7)

  3. 2017

    Early code for the Mononoke server published on GitHub (May)

  4. 2022

    Sapling client open-sourced, with Git support and ReviewStack (November 15)

  5. 2026

    Release 0.2.20260929 (September 29); Anthropic cites Mononoke as prior art for Scion (October)

Sources10 · facts checked 20 October 2026

Improve this page on GitHub