|
|
|
|
|
|
by dig1
947 days ago
|
|
|
> 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. 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. |
|
|
Not really; it just means you misunderstood what I meant by "large projects". The Linux kernel is not nearly as large as most company codebases.
> 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.
Sounds like you just don't have any experience of this sort of thing so don't appreciate the problems. You update the library in one repo and test it in another because that other repo is using the library. You want to make sure your library update doesn't break it.
If you don't test all of the dependants of your library then you're massively increasing the risk of breakage (plus all the other downsides) just so you can use separate repos. That isn't worth it.