Why Facebook and Google Turned Away from Git

In April 2005 a licensing breach forced the BitKeeper author to revoke the free‑use permission for the Linux community, leaving Linux without a source‑code management tool. Linus Torvalds responded by creating Git, while Olivia Mackall released Mercurial 0.1 a few weeks later.

Both Git and Mercurial were born at the same time, but Git quickly became the mainstream choice because of Linux’s influence. Facebook adopted Git for its rapidly expanding codebase, adding 44 000 files and 17 million lines of code in 2013—surpassing the Linux kernel.

Facebook’s monorepo strategy (placing almost all projects in a single repository) exposed Git’s performance limits: basic Git commands took up to 45 minutes on simulated future repository sizes, threatening the entire development workflow.

After consulting the Git community, Facebook was told the repository was simply too large and should be split. The community had little incentive to redesign Git for such an extreme use case.

Facebook then evaluated Perforce, but found critical consistency defects that the vendor did not prioritize fixing, so it was discarded.

A Mercurial‑using engineer suggested trying Mercurial. Mercurial’s clearer codebase, Python implementation, and extensibility made it a better fit. By integrating Facebook’s file‑watching tool Watchman into Mercurial, file‑status checks became five times faster.

Further, Mercurial’s filelog abstraction enabled Facebook to build remotefilelog, which stores large history on the server and downloads data on demand. This change boosted clone and pull speeds by more than tenfold, turning multi‑minute operations into seconds.

Building on these extensions, Facebook created a virtual file system called EdenFS, which presents the repository as if it were local while fetching files only when needed. The Mercurial community supported Facebook’s extensive patches—over 500 contributions—including new graph algorithms, C‑rewritten performance‑critical paths, and storage optimizations.

The combined effort resulted in a new version‑control system named Sapling , which merged Mercurial’s fork, remotefilelog, EdenFS, and stacked commits into a cohesive tool.

Google faced a similar monorepo challenge but on an even larger scale: by 2015 its codebase contained 2 billion lines of code occupying 86 TB, with virtually all Google products stored in a single repository. Initially Google used the commercial system Perforce, but as the codebase grew, Perforce’s CPU load, TCP failures, and maintenance overhead became untenable.

Like the Git community, Perforce suggested splitting the repository, which Google rejected. Instead, Google embarked on a four‑year effort to design and implement a clean‑room replacement, Piper , avoiding any direct reuse of Perforce APIs to sidestep technical debt and legal risk.

The migration from Perforce to Piper required building over 300 internal tools and took four years, but ultimately gave Google a version‑control system capable of supporting billions of lines of code and tens of thousands of engineers.

Both Facebook and Google’s experiences show that while Git remains the most suitable choice for most teams, the extreme scale of these internet giants forced them to abandon Git in favor of heavily customized or entirely new solutions that are not easily replicable by ordinary companies.