Earlier quoted context omitted.
They explain it here: https://engineering.fb.com/core-data/scaling-mercurial-at-fa... The official reason is that the "internals of Git" weren't conduce to the kinds of invasive changes they needed/wanted. But I think the truth is closer to being that it was going to be too hard/slow to get those invasive changes past the Git mailing list. Here's an example of a FB eng reaching out to the mailing list: http://git.661…
This was a super fun read, thanks for sharing. The mailing list piece is from 2012, and describes how git is very slow on a synthetic repo with millions of files and commits. Today, my current place of work has a monorepo that’s approaching the size described in this mailing list, but git seems to be holding up just fine. If you checkout a branch that’s far enough away from master it takes a minute, but add, rebase,…
Re: EdenSCM – A cross-platform, scalable source control management system
#31Free RAM has a huge influence of how much of the filesystem tree is cached in kernel. This is visible from just `time find`. It could just be a case of developer workstations going from e.g. 4 GB to 16 GB.