[nkozyra]

> If a mono-repo has a terabyte of code, or if 10 small repos have 1/10th a terabyte each, what have you really gained?

If it's a small company where every developer touches every part of the application, sure. Taking the FAANG approach if you're not part of that acronym sounds like introducing inefficiency.

[klodolph]

If it's a "small" company then I'd expect that one Git repo would do just fine for all or at least most of the code. When I think small, I think ~10 or 20 developers. If you have reasonable hygiene about things like keeping binaries out of your Git repo (excluding consideration of e.g. LFS here) then the whole repo size will stay fairly reasonable. As long as you have one or two Git mavens on your team it should be dandy.

I'd expect to see problems with this approach once you get into the 100s or 1000s of developers. The tooling for this scale of repository isn't as mature.

[nkozyra]

Sorry, what am I missing? That's exactly what I was saying - this stops making sense anywhere in between "small" and "the big boys"

[klodolph]

> Taking the FAANG approach if you're not part of that acronym sounds like introducing inefficiency.

Is this not saying that small companies should avoid monorepos?

[nkozyra]

Specifically excluded in the preceding sentence in my post.