Why Facebook Doesn't Use Git

Nearly every major tech company runs on Git. Facebook, now Meta, is the exception, and the reason behind it says a lot about what happens when you take a single engineering idea to its absolute limit: the monorepo.

One repository to rule them all

Facebook used to run on Git like everyone else. But instead of splitting its systems into many repositories, Facebook kept everything inside a single one, every feature, every service, the entire product. This is called a monorepo.

When Git started to buckle

As the company and its codebase grew, the monorepo grew with it. Eventually it got so large that basic Git operations, a pull, a fetch, a checkout, could take on the order of thirty minutes. For an engineering org that ships constantly, that's not a minor inconvenience. It's a tax on every single change anyone makes.

Facebook went directly to Git's core maintainers to see if the tool could be made to handle a repository at that scale. The answer was clear: split the monorepo into smaller repositories. That's how Git is designed to scale.

Why splitting wasn't an option

But breaking up the monorepo wasn't feasible for Facebook. It wasn't an accident, it was central to how the company shipped software: one version of the truth, atomic changes across projects, shared tooling for everyone. Undoing that would have meant rearchitecting how thousands of engineers worked.

The Mercurial years

So Facebook's engineers looked elsewhere and landed on Mercurial, another distributed version control system. Mercurial was easier to extend, and its community was open to accepting the deep changes Facebook needed. Facebook migrated its entire codebase over and invested heavily in improving Mercurial's performance for repositories at its scale, much of which eventually made its way back into the project itself.

Building Sapling

Even a heavily customized Mercurial eventually hit its own ceiling. So Meta went further and built its own version control system from scratch: Sapling. It took the ideas that had worked in Mercurial and rebuilt them specifically for monorepo scale, and Meta open-sourced it in 2022.

The other half of the problem: EdenFS

A faster version control client couldn't fix the whole issue on its own. By this point, Meta's codebase was so large that no single engineer's laptop could hold a full checkout of it, there simply wasn't enough disk space, and even if there were, checking it out would take forever.

Meta's answer was EdenFS, a virtual filesystem that sits underneath the version control system. Instead of materializing every file in the repository onto a machine, EdenFS fetches a file only the moment an engineer actually needs it, when they open it, edit it, or build it. From the engineer's point of view, the entire repository appears instantly, even though almost none of it has actually been downloaded.

The takeaway

Together, Sapling and EdenFS are why Facebook doesn't use Git today. Not because Git failed, but because Facebook pushed one idea, the monorepo, far enough that it needed tools built specifically for it.

What you can learn from this

You don't need Facebook's scale for this story to be useful. A few things generalize well beyond monorepos.

• Tooling debt compounds quietly. A slow git pull doesn't feel like a crisis until it's costing every engineer thirty minutes a day, at which point it already is one.
• "The tool wasn't built for this" is a fact, not a verdict. If the constraint is truly core to how you work, the answer can be to build the missing piece, not to abandon the architecture.
• Lazy loading isn't just a frontend pattern. EdenFS applied the same idea, fetch only what's actually needed, to a filesystem. The pattern generalizes far beyond version control.
• Building infrastructure in-house is a multi-year bet, not a quick fix. It only pays off at a scale where the alternative is worse. Most teams should borrow the judgment here, not the solution.
• Sometimes the real problem isn't the one you went looking for. Facebook set out to fix Git performance and ended up rebuilding version control and the filesystem underneath it.