Why Facebook Doesn't Use Git

Facebook’s shift away from Git and toward Mercurial (and then custom tooling built on top of it) came down to one practical bottleneck: Git’s performance degraded as the company’s monorepo grew to massive scale. Around 2012, engineers began feeling Git operations slow down—not always catastrophically, but enough to justify a serious investigation. The key pain point wasn’t just “cloning feels slow”; it was the cost of Git examining (statting) huge numbers of files, with latency compounding as file counts rose.

A 2014 Facebook blog post (and later follow-ups) described Git’s scaling limits in terms of repository size. The company’s codebase was projected to grow far beyond what Git could handle comfortably. In a simulation meant to match expected growth, basic Git commands reportedly took over 45 minutes to complete. The prospect of waiting for “engineers are complaining” before fixing the problem was unacceptable; by the time that happened, the repository would be too unwieldy to rescue. The team concluded that damage control would be Herculean, so they pursued a cleaner solution early.

Before committing to Mercurial, the investigation explored alternatives. Perforce was considered, but an architectural flaw around local consistency between readers and writers undermined confidence. Other systems like BitKeeper were also evaluated and quickly ruled out. Mercurial emerged as the leading candidate because it offered performance comparable to Git while being architecturally simpler—implemented in Python with object-oriented patterns and designed to be extensible. That extensibility mattered: the team wanted a version control system that could be shaped to their needs rather than forcing their workflow to fit a tool that couldn’t scale.

The next phase focused on feasibility and adoption. Engineers attended a Mercurial hackathon in Amsterdam to validate that the Mercurial community was welcoming and that maintainers would support aggressive changes. Once convinced, the migration required winning over the rest of the organization—an inherently political and emotional process for developers whose daily workflows depend on tooling. The rollout avoided flame wars by mapping common Git commands and workflows to Mercurial equivalents, measuring which Git operations were used most, and creating channels for developers to raise edge cases.

After the company cut over to Mercurial, Facebook contributed performance improvements back to the project, helping make it a better fit for large monorepos. It also extended Fabricator to support Mercurial-style “diffs,” enabling “stacked changes” that unlock smoother code review and parallelization—changes that later influenced tools like Graphite. The broader takeaway from the accounts is that major engineering tool decisions are often driven by human factors—who is willing to collaborate, how migrations are socialized, and whether teams can translate workflow pain into a workable technical plan—more than by abstract technology comparisons alone.