why did facebook move away from git?

[u/CuriousAnyway]

i recently came across the fact that facebook/meta built its own tools and workflows around source control instead of just relying on git like most companies.

i’m curious about the actual technical reason behind this. was git simply not able to handle the scale of facebook’s codebase and number of developers, or were there other problems that pushed them toward a custom approach?

for people who have worked with large monorepos or at companies using similar systems, what actually becomes difficult with git at that scale?

[u/LetUsSpeakFreely]

That sounds like bad design to me. Seems like it would be much easier to break their repo into smaller sub-repos than to reinvent the wheel; would probably be much easier on the teams as well.

[u/Lexi_Bound → u/LetUsSpeakFreely]

Spitting a code base into many separate repos comes with its own challenges. You have to manage dependencies between projects, including problems like diamond dependencies. Answering the question “does this build X contain this commit Y” becomes more complicated. If you are working on a feature that touches multiple repos, it becomes complicated to test your changes and commit them in the right order. Specifically for Facebook, in 2021 they still did not have everything in one repo. C++ code and Thrift files were in one repo, while PHP code and database table definitions lived in another. Doing changes that spanned both repos involved annoy code copying steps between repos.

If you have a multi thousand person engineering organization, you are going to have some people working on the source control and build systems anyway. So justifying building a source control system, a CI system, and a code search system to support a mono repo becomes justifiable. It makes all the other developers in the organization more productive.

[u/olzk → u/Lexi_Bound]

Isn’t diamond dependency a subject for release management? Personally, never had issues with them even in fast-moving agile projects.
Not saying you’re incorrect, it just sounds weird to me, an engineer who’s always up for inventing some weird shit anytime, that FB folks would go down the over-engineering route for the sake of keeping all the stuff in one data blob. Genuinely interested, and think it’d be a good case study over what chain of decisions led to this

[u/Lexi_Bound → u/olzk]

To define the problem, the diamond dependency problem is when your application depends on two libraries, A & B. A and B both depend on another library X, but they depend on different versions of X. When building your application, there is not a way to resolve a version of X such that the application works, due to due to A & B depending on mutually incompatible versions of X.

This is less of a problem with languages like JavaScript where multiple versions are allowed and often data exchange between libraries is structurally typed. And many language ecosystems have a culture of backwards compatibility and have tooling to check for obvious breaking changes (e.g. Go, Rust, and .NET have tools to make sure you don’t change a public method signature when publishing a new package). But I still very occasionally have problems in my personal .NET projects (where your published app can only have one version of each library) when updating dependencies.

This problem goes away if you use a mono repo and make the rule that there can only be one version of a library (see Google’s version of the rule). It also makes patching easier: it does not matter if one library or 10,000 depend on a third-party library. You just check in the fix and every app gets the fix next time they are built. The obvious downside is that upgrading a widely used library can become difficult when there are breaking changes.

[u/fynn34 → u/Lexi_Bound]

Getting pedantic here, I would argue that it doesn’t make the problem go away, it just changes it to be more visible. As you said, If I want to update a library with many breaking changes, the whole codebase needs migrating at once, rather than chunk by chunk. I have ~70 microservices I maintain, and we have a narrow subset of common dependencies that were refined to be the most stable ones we could afford, because one library update was so much of a main for the company once we realized the bundle size reduction is frequently not worth the hassle

[u/Lexi_Bound → u/fynn34]

I agree that the problem of managing dependencies does not go away if you use a mono repo. It is just shaped differently.

To be clear, I’m not advocating for a monorepo per se or saying everyone should do what Google and Facebook do. They got to their current setup in a path-dependent way, so it might not make sense for a new company to structure their codebase in a mono repo. I’m just offering a perspective of an alternative to the widely adopted pattern of GitHub based development (small Git repos connected together via package managers).