If you've been living under a rock, Sapling is the version control system Meta built because its monorepo grew so large it would crater regular git. The wild part: they open-sourced it, the desktop UI ships free, and it talks to GitHub remotes natively.
That combination matters. You can point Sapling at an ordinary GitHub repo today, get the Meta-engineer workflow, and your teammates keep using git like nothing happened. No migration meeting required.
What Is Sapling SCM?
Sapling is Meta's source control client — the thing their engineers actually type all day — released as open source. The mental model is closer to Mercurial than git, which makes sense given Meta's history with Mercurial before evolving it into this.
The binary is sl, two characters of pure ergonomics. Commits are first-class citizens, branches are mostly invisible, and your working state is always something the tool can draw for you as a tree.
Crucially, it's git-compatible on the remote side. Clone from GitHub, push to GitHub, open PRs on GitHub. Sapling is a client-side opinion, not a hosting ultimatum.
How Sapling Works
Commits first, branches never
In git you juggle branch names because commits without a branch quietly fall into the reflog void. Sapling flips that: every commit you make stays visible and reachable, so named branches become optional decoration rather than load-bearing infrastructure.
You move around with sl goto and a hash prefix. You stack commits on top of each other, amend anything in the middle, and Sapling automatically restacks the children. In git that's an interactive rebase and a small prayer.
Smartlog, the actual killer feature
Smartlog is the feature you'll show your colleagues. It draws a clean ASCII tree of everything you're working on, what's pushed, what's stacked, and what's behind main. No more git log --graph --oneline --decorate incantations.
It only shows commits you actually care about — your work plus main — instead of the entire history of the universe. That's the difference between a status display and an archaeology dig.
Sapling vs Git (and the Other Successors)
Git's superpower is ubiquity. Every CI system, every IDE, every Stack Overflow answer assumes it. Sapling's superpower is that its everyday commands — goto, amend, undo — map to what you meant, not to a graph theory lecture.
The honest comparison: git makes easy things weird and hard things possible; Sapling makes easy things easy and hides the hard things behind sane defaults. If you've ever explained detached HEAD to a junior dev, you already know which philosophy wins for daily work.
It's not the only contender in the “git, but humane” category either. Jujutsu takes a similar commits-first swing with the bonus of using your existing git repo as the backend — worth a look if Sapling's Meta-flavoured tooling feels heavy for your taste.
How to Install and Run Sapling
Setup is genuinely boring, in the good way. Homebrew on macOS, then clone straight from GitHub with sl and go.
{`# install
brew install sapling
# clone a github repo with sl
sl clone https://github.com/aiden/aidxn-design
cd aidxn-design
# the killer command
sl smartlog`}First-run tip: run sl smartlog immediately after cloning, then keep running it compulsively. It's the map. Every other Sapling command makes more sense once you're looking at the map.
The daily stack workflow
The workflow Sapling is built around is stacked commits: a chain of small, reviewable changes instead of one branch-blob per feature. Pull and rebase the stack, hop to any commit, amend it in place, submit the lot as PRs.
{`# pull rebase your stack on top of main
sl pull --rebase
# move to a commit by hash prefix
sl goto a3f
# amend the current commit and restack children
sl amend
# push the current stack as PRs
sl pr submit`}sl pr submit is the sleeper hit — it turns your local stack into GitHub pull requests without you manually creating a branch for each one. The branch bookkeeping git forces on you just... evaporates.
Undo, because you will need it
Sapling also ships a real undo. Not “go spelunking in the reflog and reconstruct the hash” — an actual command that walks back the last operation.
{`# fat-fingered an amend? walk it back
sl undo
# changed your mind again
sl redo`}This one feature removes most of the fear from history editing. Amend aggressively, restack freely — if it goes sideways, undo it and carry on.
The Catch
Sapling expects Meta-scale infrastructure to fully shine — the virtual filesystem (EdenFS), the Mononoke server, the works. On a normal GitHub repo you get the client experience, which is great, but the headline scale story isn't really yours to claim.
The ecosystem of plugins is approximately zero. Your CI speaks git, your IDE speaks git, your hooks speak git. Sapling coexists with all of that, but you're the odd one out on the team, and every integration question starts with “well, in git...”.
And the muscle-memory tax is real. The commands are friendlier, but the workflow instincts around branches take a couple of weeks to unlearn — expect to type git reflexively for a while.
The Verdict
For a solo dev shipping Astro sites on Netlify, Sapling is overkill — but smartlog alone makes it worth a weekend. If you ever inherit a monorepo north of 10GB, you'll be glad you already know sl.
If your actual pain is juggling parallel checkouts rather than fighting the commit graph, git worktrees might scratch the itch without switching tools. But if the itch is git's UX itself, Sapling is the most polished escape hatch you can install today. Plot twist: the desktop UI is genuinely good.