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.661346.n2.nabble.com/Git-performance-results-on-a...
Google interestingly also still contributes to mercurial[0], but I don't think has said why externally officially.
But yes, my understanding is that mercurial is much easier to replace parts of the flow without entirely hacking the codebase to bits. Microsoft's solution for git required them to fork the code base, which I still don't think has been fully merged with upstream yet? And as others said, the mercurial community was more open to enterprise contributing things than git can be.
It was very promising but the suddenly stopped updating and then (more or less intentionally it seemed) links stopped working, but the site is still up 7 years later...
I suppose FB has better tools. But I won’t touch this until the ecosystem is sufficient (and also, because git and hg are perfectly sufficient for the monorepo I oversee)
This was already starting to become true even before FB switched to Eden, and before it switched to Mercurial (grepping, for example, was already back in the Git days being served by a custom grep service).
However, perhaps OS level support would be preferred. Imagine you have a type of symbolic link that is not just followed, but executed when you access it. That would be really powerful and would allow this kind of optimization. And you wouldn't even need to install or run anything.
https://docs.bazel.build/versions/master/remote-caching.html
The SCM, the CI, the Merge Request system, the build system, they're all tied together into a single thing. Google has open sourced parts of it but nothing exists as a whole unit the way Google does it
To describe it as a filesystem matches my thinking [0]: "It already resembles a network file system, so it should provide an interface nearly as easy to use."
If it really takes off as an Open Source project, we might be able to "mount" repostories eventually.
For personal projects, it’s absolutely the bees knees. I can have multiple checkouts of the same repo, ask fossil about every single repo I have, has a really pleasant CLI, has a web-interface (which I personally hardly use anymore), manages tickets, ... sort of github in-a-box, but more pleasant.
"EdenSCM is not a distributed source control system. In order to support massive repositories, not all repository data is downloaded to the client system when checking out a repository"
Which is about the same thing, mercurial was built to be at least somewhat pluggable, so facebook could build their extensions independently, and work to get a subset of them integrated into mainline. Git is designed so it can be built on top of, but not really under or within.
At a technical level I believe both Google and Facebook engineers make core changes to mercurial when they need to so I don’t think that’s the root philosophical difference.
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, commit, status and blame are all negligibly impacted speed-wise. The only issue we run into is rejected non-conflicting pushes to master during peak hours, with maybe several dozens of engineers trying to merge and push master simultaneously.
Does anybody have any insight into what’s changed in git internally since 2012 to support bigger repos?
Over 8 years and tens of those changes, it adds up to a significant performance improvement.
> Have you considered upgrading all of engineering to SSDs? 200+GB SSDs are under $400USD nowadays.
Funny, but I'm starting to wonder if there's an affect-based complement to Conway's Law.