Why Facebook doesn't use Git
graphite.dev
Why Facebook doesn't use Git
1–10 of 22 posts
Re: Why Facebook doesn't use Git
#2Very cool, thanks for sharing. Despite never actually hearing about 'stacked prs' before, I've often encountered the issue and it makes me wonder why a solution like this isn't actually part of Git itself.
Re: Why Facebook doesn't use Git
#3How much better was performance? Did people prefer or not prefer the new workflows?
Re: Why Facebook doesn't use Git
#4Ctrl+F 'Sapling'
Ctrl+F 'Eden'
Yeah the author of this doesn't really know what's going on with regards to source control at Facebook/Meta.
Meta doesn't actually use Mercurial and hasn't for several years now. They basically wrote their own custom centralized version control that uses Mercurial-inspired client commands in order to adapt to the scale of their massive repos. Actual Mercurial scales just as bad as ever if the repo is too large because that breaks a fundamental assumption of distributed version control.
Massive repos simply don't work with the traditional model of "no master server" distributed version control. In DVCS, a client checkout is supposed to contain the entire repo metadata. That's why the git people told Facebook that they were doing it wrong.
Anyways, stacked diffs are great but they're orthogonal to why Facebook doesn't use git. They use their own thing for the same reason that Google uses piper and why some places still use Perforce. They use it because they want to have massive monorepos and DVCS just doesn't work well for that.
Re: Why Facebook doesn't use Git
#5For some reason I thought part of the reason was ex-googlers at Facebook.
But it actually seems that it was somewhat the other way around. Mercurial is used at Google partially because Facebook was already using it.
Maybe someone has a more concrete timeline of the cross pollination of VCS between the two.
Re: Why Facebook doesn't use Git
#6Ctrl+F 'Sapling' Ctrl+F 'Eden' Yeah the author of this doesn't really know what's going on with regards to source control at Facebook/Meta. Meta doesn't actually use Mercurial and hasn't for several years now. They basically wrote their own custom centralized version control that uses Mercurial-inspired client commands in order to adapt to the scale of their massive repos. Actual Mercurial scales just as bad as ever…
I'm not sure that this continues to be true, now that Git supports partial clones[1]. It's now a fully supported feature in Git to work with only a partial copy of the code and metadata. In my experience, this plus an fsmonitor[2] makes Git work fine on very, very large repos. This is how Microsoft scaled Git to work with their massive Windows monorepo[3]. (That particular article talks about the earlier work using Git VFS, but it eventually turned into these extensions that got upstreamed into Git, as documented in the Scalar repo[4].)
[1] https://github.blog/2020-12-21-get-up-to-speed-with-partial-...
[2] https://github.blog/2022-06-29-improve-git-monorepo-performa...
[3] https://arstechnica.com/information-technology/2017/02/micro...
Re: Why Facebook doesn't use Git
#7[flagged]
Re: Why Facebook doesn't use Git
#8Ctrl+F 'Sapling' Ctrl+F 'Eden' Yeah the author of this doesn't really know what's going on with regards to source control at Facebook/Meta. Meta doesn't actually use Mercurial and hasn't for several years now. They basically wrote their own custom centralized version control that uses Mercurial-inspired client commands in order to adapt to the scale of their massive repos. Actual Mercurial scales just as bad as ever…
Recently open sourced too https://github.com/facebook/sapling
Re: Why Facebook doesn't use Git
#9How much better was performance? Did people prefer or not prefer the new workflows?
The overall performance was massively better. Operations that would take minutes in Git in a large repo would take seconds (and eventually sub-seconds) in Facebook's Mercurial. Latency was a common complaint though. With Git in a small repo, commands can finish in milliseconds. With Facebook's Mercurial most commands took at least a few hundreds milliseconds (Python startup and module initialization alone could take that), which makes the CLI feel more sluggish than most people preferred.
Beyond performance, a lot of design effort was put into the workflows as well. The resulting user experience is significantly different from the open source Mercurial experience and in the long run the vast majority of people preferred the new workflows. Even some of the die-hard Git fans who complained about the transition. Part of the motivation of open sourcing Sapling was because ex-employees wanted to use it outside the company.
(Source: I was on the Facebook source control team for ten years.)
Re: Why Facebook doesn't use Git
#10Ctrl+F 'Sapling' Ctrl+F 'Eden' Yeah the author of this doesn't really know what's going on with regards to source control at Facebook/Meta. Meta doesn't actually use Mercurial and hasn't for several years now. They basically wrote their own custom centralized version control that uses Mercurial-inspired client commands in order to adapt to the scale of their massive repos. Actual Mercurial scales just as bad as ever…
I'm not sure that this continues to be true, now that Git supports partial clones[1]. It's now a fully supported feature in Git to work with only a partial copy of the code and metadata. In my experience, this plus an fsmonitor[2] makes Git work fine on very, very large repos. This is how Microsoft scaled Git to work with their massive Windows monorepo[3]. (That particular article talks about the earlier work using G…
Yeah, these all seem like parallel or inspired developments of the same thing in git. But they're relatively recent and when you use this stuff git basically ceases to be a DVCS system (though the modern git + GitHub workflow mostly works like centralized version control already)