Facebook internal development started out on Subversion with a Git mirror but switched to Mercurial for source code control, achieving what some who worked there called “far and way the best” developer tooling” – yet most developers use Git and that is unlikely to change.

Greg Foster, co-founder and CTO at code review tools company Graphite, wrote back in March about why Facebook does not use Git. The Graphite tools, he said, were “inspired by internal Facebook tooling,” though he has never worked there. He investigated why it is that Facebook does not use Git.

Ostensibly the problem was one of scale. Facebook has a huge codebase, and is a monorepo, meaning that all the code is in one repository. The engineers projected what would happen as the codebase continued to grow, discovering that “basic Git commands took over 45 minutes to complete.”

Facebook approached the Git maintainers and was told to break down the codebase into multiple repositories. The company then approached the Mercurial team and found it open to cooperation. “Facebook contributed performance improvements to Mercurial, making it the best option for large monorepos,” Foster reported.

A developer said on Reddit: “I’ve worked a lot of places and Meta’s developer tooling was far and away the best.” Another said that “I’m there, and I’ll be honest, it’s weird as fuck but actually works”

Should more developers therefore use Mercurial? Possibly, though Foster observed that “a decade later, Git has made significant improvements to support monorepos better.”

Facebook though is not a typical use case. The company has huge resources which it invests in optimizing its developer tooling. It looks as if Facebook still makes some use of Git, in the form of Sapling SCM which is Git-compatible, but has a CLI “originally based on Mercurial.” It is significant that Sapling includes a virtual file system called EdenFS, which is used in production within Meta,” but “currently does not build in an open source context and is not yet supported for external usage.” It is an example of custom tooling that works well internally, but is not suitable, at least in respect EdenFS, for the rest of us.

Git is complex and not always intuitive. For example, adding a tracked file to a list in the configuration file .gitignore does not remove it from tracking. “To stop tracking a file, we must remove it from the index: git rm –cached <file>” explains a StackOverflow answer with nearly 9,000 upvotes. Another wrinkle is that this command will delete the file on the next git pull, for all developers. If the dev needs the file to exist locally, but not be tracked, further steps are needed.

Nevertheless, the rise of Git seems unstoppable. In 2020, Atlassian removed Mercurial support from Bitbucket cloud, in favour of Git, citing the overhead involved in supporting two systems. In 2022, the WebKit open source project, used by Apple for Safari, migrated from Subversion to GitHub. Last year, Mozilla moved Firefox development from Mercurial to GitHub.

Currently, according to a StackOverflow survey, Git has a 93.87 percent usage share, with the second place being Subversion with 5.18 percent.

One of the issues for developers is that familiarity with Git (for all its quirks) means that new hires get up to speed quickly. Another is that Git-based platforms like GitHub and GitLab include a host of additional tools, for issue management, discussions, security features, and CI/CD (Continuous Integration/Continuous Delivery) which add value.