Excellent Reads

1565 readers

1 users here now

Are you tired of clickbait and the current state of journalism? This community is meant to remind you that excellent journalism still happens. While not sticking to a specific topic, the focus will be on high-quality articles and discussion around their topics.

Politics is allowed, but should not be the main focus of the community.

Submissions should be articles of medium length or longer. As in, it should take you 5 minutes or more to read it. Article series’ would also qualify.

Please either submit an archive link, or include it in your summary.

Rules:

Common Sense. Civility, etc.
Server rules.

founded 2 years ago

MODERATORS

Iliveonsaturdays

[email protected]

AwesomeLowlander

Why Facebook doesn’t use Git (graphite.dev)

submitted 5 months ago by [email protected] to c/longreads

9 comments fedilink hide all child comments

Monorepos, performance problems, and a lot of asking

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 25 points 5 months ago (3 children)

Really good read.

One thing they didn't cover was why the monorepo is so appealing to facebook

[–] [email protected] 11 points 5 months ago

If I had to guess I'd say it's because fundamentally Facebook development is about deploying servers.

As you move through the main branch, at any commit, you should have something that you can deploy. The moment you split the repo you lose this, and need to worry about keeping multiple repos aligned.

[–] conciselyverbose 11 points 5 months ago

Our code base has grown organically and its internal dependencies are very complex. We could have spent a lot of time making it more modular in a way that would be friendly to a source control tool, but there are a number of benefits to using a single repository. Even at our current scale, we often make large changes throughout our code base, and having a single repository is useful for continuous modernization. Splitting it up would make large, atomic refactorings more difficult. On top of that, the idea that the scaling constraints of our source control system should dictate our code structure just doesn’t sit well with us.

This is from the blogpost it links near the beginning. Also worth a read if you're interested.

[–] [email protected] 7 points 5 months ago

I personally love a monorepo. It has to be managed effectively by the team, but the benefits are great. Most of it boils down to making more effective incentives for maintenance and care for downstream effects because "we all live here". There are tradeoffs and it's not for every situation or team though, for certain.