Why Facebook and Google Abandoned Git for Custom Version‑Control Systems

BitKeeper licensing breach and birth of Git and Mercurial

In April 2005 the BitKeeper author revoked the free‑use license for the Linux community after a licensing violation. Linus Torvalds paused kernel development and created Git. A few weeks later Olivia Mackall released Mercurial 0.1. Both systems were introduced as distributed version‑control tools with an emphasis on extensibility.

Facebook monorepo scaling and Git limitations

Facebook adopted a monorepo strategy. In 2013 the repository grew by 44 000 files and 17 million lines of code, surpassing the Linux kernel. Simulated growth tests showed that basic Git commands could take up to 45 minutes, threatening the productivity of the engineering organization.

Evaluation of alternatives

Git community response: split the repository, which was deemed unsuitable for Facebook’s single‑repository model.

Perforce evaluation: identified local‑consistency defects that the vendor did not prioritize fixing, leading to abandonment of this path.

Adoption of Mercurial and performance engineering

A long‑time Mercurial user suggested trying Mercurial. Mercurial’s Python‑based, object‑oriented codebase was considered easier to extend than Git’s C implementation. Integration of Facebook’s file‑watching tool Watchman allowed Mercurial to obtain file‑status information without traversing the entire working tree, improving status checks by more than five times.

Filelog, remotefilelog and EdenFS

Mercurial provides a filelog abstraction. Facebook built remotefilelog on top of filelog to store large historical data on a server and download it on demand. This change increased clone and pull speeds by over tenfold, reducing operations that previously required minutes to a few seconds.

To further reduce on‑disk footprint, Facebook developed EdenFS , a virtual file system that presents the repository as if all files were present locally while materialising files only when accessed. EdenFS operates at the operating‑system level, complementing the on‑demand history provided by remotefilelog.

Creation of Sapling

Facebook merged the Mercurial fork, remotefilelog, EdenFS, and related extensions into a new version‑control system named Sapling . The UI/CLI was redesigned to improve developer ergonomics.

Google monorepo scaling and Perforce limits

By 2015 Google’s monorepo contained roughly 2 billion lines of code (≈86 TB), encompassing almost all Google products. Google had used Perforce for 11 years, but as the codebase grew the Perforce infrastructure suffered CPU saturation and frequent TCP connection failures, making the system increasingly unmaintainable.

Design and migration to Piper

Google chose to build a new system, Piper , using a clean‑room approach to avoid reusing Perforce code and to eliminate legal risk. The migration from Perforce to Piper took four years. Piper’s design avoided the technical debt of directly copying Perforce’s API and provided a purpose‑built architecture for a multi‑billion‑line codebase.

Comparative observations

Both Facebook and Google pursued monorepo strategies that exceeded the design limits of mainstream VCS tools.

Facebook extended Mercurial, achieving >5× faster file‑status checks and >10× faster clone/pull operations, then consolidated the work into Sapling.

Google built Piper from scratch, investing years of engineering effort to support its massive codebase.

The engineering effort required for these custom solutions is substantial and not practical for most organizations; for typical teams Git remains the most suitable version‑control system.

Code example

来源丨经授权转自 码农翻身（ID：coderising）
作者丨liuxin