Why Facebook Dropped Git for Mercurial: Performance and Community Factors

Why Facebook Dropped Git

According to a 2014 Facebook engineering blog, the company started with Git as its default source‑control system, but by 2012 the size of its codebase—"many times larger than the Linux kernel, which has 17 million lines of code and 44 000 files"—made Git operations noticeably slow.

The core issue was the stat‑ing of every file. As the number of files grew, Git’s file‑status checks became increasingly time‑consuming. Simulations of a repository the size Facebook expected in the coming years showed basic Git commands taking more than 45 minutes to complete, prompting engineers to investigate a solution before the problem became untenable.

Engineers first contacted Git maintainers to ask what would be required to improve Git’s handling of such large monolithic repositories. The maintainers suggested splitting the repository into multiple smaller .git repos, but warned that this was not a good idea for Facebook’s workflow. When Facebook’s team presented the scale of their repository (over 1.3 million files), the Git community showed little interest in addressing the performance gap, and the maintainers refused to prioritize the needed changes.

Considered Alternatives

In 2012, few alternatives to Git existed for a repository of Facebook’s magnitude. The team evaluated the closed‑source Perforce solution, which Google had previously used, but discovered architectural flaws in Perforce’s read/write consistency model that the sales engineers could not resolve. Other candidates such as Bitkeeper were quickly dismissed.

Mercurial emerged as the final option. Its performance was comparable to Git’s, but its architecture—written in Python with an object‑oriented design—was perceived as clearer and easier to extend than Git’s complex Bash/C codebase. One engineer on the evaluation team already had extensive Mercurial experience, prompting the team to attend a Mercurial hackathon in Amsterdam for deeper investigation.

At the hackathon they found an extensible system and a supportive maintainer community that welcomed Facebook’s contributions, reinforcing the decision to adopt Mercurial.

Migrating the Entire Engineering Organization

After the hackathon, Facebook committed to the migration. Convincing the broader engineering organization was challenging because developers are highly sensitive to tooling changes. The team proceeded cautiously, mapping every common Git command to its Mercurial equivalent and collecting statistics on Git command usage across the company.

They opened channels for engineers to voice concerns and discuss edge cases. Contrary to expectations of heated debates over complex merges, most engineers responded positively, with no one shouting about special cases. Eventually the migration was completed. Facebook contributed performance improvements to Mercurial, making it the optimal choice for a single massive codebase. Evan Priestley extended Phabricator to support Mercurial, and Facebook built a "stacked diffs" workflow on top of Mercurial’s diff model, enabling parallel code‑review processes.

Conclusion

The key lesson is that major technical decisions are often driven by people rather than pure technology. Facebook chose Mercurial not because it was objectively faster than Git, but because Mercurial’s maintainers were open to collaboration and the community responded positively to Facebook’s needs. The decision was the result of extensive communication, careful analysis of performance constraints, and a willingness to adopt a tool whose ecosystem aligned with the team’s collaborative values.