| > Git is very good with large repos Not really. It only very recently got support for partial clones, sparse checkouts (still experimental!) `git status` daemon (only on Windows and Mac!), etc. And that's only because Microsoft is pushing it. > My guess is that people adopt monorepos because they aspire to be Google-scale, but it usually doesn't make sense for their workflow. Rubbish, it's nothing to do with wanting to be Google-scale. In fact being Google-scale makes a monorepo more difficult and require custom tooling. The reason people like monorepos is because they don't have the downsides of multirepos: * Cross-repo changes are very difficult to do and even harder to test. * Testing code becomes very difficult. For example if you update a library that's in one repo, how do you test all the things that depend on it? Very difficult with multirepos, trivial with monorepos. * Git's support for submodules is really bad. The downside of monorepos is that they are big and slow, but they work fine as long as you aren't Google scale. |
Which only proves my comment that git is not designed for bigcorp view of monorepos. Kernel is monorepo and works fine.
> The reason people like monorepos is because they don't have the downsides of multirepos:
The reason people like monorepos is that they are lazy to properly organize development process. If you update library in one repo but test it in another, I'd say you need to reconsider your pipeline. But, to each their own.