kanu666

Sorry, there is a quote from the article: "Kudos to other members of the Source Control team — Alex Sadleir, Wesley Li, Adam Murray, Matthew Chhoeu — who work on improving git performance at Canva"

So I assume 5 people working specifically on Git performance ;-P

Git staring to break at 200-300 engineers pushing into it. Scaling git would take 200 more :)

Thanks for the clarification. How many people work on Developer Productivity in total and what is the percentage from the total engineering headcount?

Usually it is considered good proportion to start with to be 10% to work on a Developer Productivity and it should increase to 15% as company grow. But regarding source control it really depends on the approach: if you are on polyrepo - then 0 is enough. If you decide to write you own source control system like Facebook or Google, then maybe couple of hundred engineers full time until the project is finished :)

Sure, and what next? So considering that on big projects CI/CD may take up to an hour (in one of my projects it took 4 hours) the feedback loop would be great

Of course, you shouldn't start a project from 10 repos. But the downside is while you live in a single repo all the tooling get tuned to work with a single repo. And then there is no way to go multi-repo when you need to.

So advice would be: start small but think big :)

If you don't have a couple of hundreds engineers who would write a custom file system for git (Microsoft), or who would take an existing source control system and nearly fully rewrite it (Facebook), or who would write a custom source control system from scratch (Google, Yandex, etc) DON'T USE MONOREPO.

Otherwise you are risking to end up in a situation when hundreds of your engineers have to spend tens of minutes every time they need to simply push their code changes.

But that's what those responses are all about: git doesn't scale, so don't use it if you need scale. If there are no tools that scale available, then change the approach so you don't need face this scaling problem at all.

But in the monorepo you almost never can do the change in a single commit as it will cause incompatibilities during gradual deployment

How would you do refactoring over monorepo if you have sparse checkout?

Don't mix up downsides of multirepo and bad composition of your microservices