[rokob]

Facebook moved to mercurial because of specific problems related to the size of their monorepo. Moreover the git maintainers were unwilling to work with Facebook to improve git to solve some of these problems. Mercurial was a better fit and was open to the help. But all that said if you don’t have a truly enormous monorepo like Facebook or Google then git is arguably the better tool given the network effects. I don’t think Facebook wanted to promote Mecurial as some vastly superior solution outside because for most people it isn’t.

[jasode]

>Moreover the git maintainers were unwilling to work with Facebook to improve git to solve some of these problems. Mercurial was a better fit

More add-on discussion including Microsoft+Git spurred by your previous comment about this: https://news.ycombinator.com/item?id=15725497

From the Facebook blog post, it seems like the key issue was Facebook's internal filesystem monitoring tool (Watchman) was easier to integrate with Mercurial than with Git:

https://engineering.fb.com/2014/01/07/core-infra/scaling-mer...

So, neither Mercurial-out-of-the-box nor Git-out-of-the-box could handle huge monorepos. But Mercurial's willingness to make some modifications made it easier for Facebook to integrated their custom tooling to avoid the slow Big-O O(n) scans for changed files.

[nextaccountic]

> From the Facebook blog post, it seems like the key issue was Facebook's internal filesystem monitoring tool (Watchman) was easier to integrate with Mercurial than with Git:

> https://engineering.fb.com/2014/01/07/core-infra/scaling-mer...

That link is from 2014, is there any more recent work to make Git use a file watcher rather than scan the whole tree?