4 ms·
I am not sure what I'm looking at here. Surely those half million files are for dozens if not hundreds of different apps, libraries and tools and surely those d
by rsp1984 3y ago
I am not sure what I'm looking at here. Surely those half million files are for dozens if not hundreds of different apps, libraries and tools and surely those do not all depend on each other, no?
Because if so, why not just use one repo per app/library/tool? Sure, if you have a cluster of things that all depend on each other, or a cluster of things that typically is needed in bulk, by all means, put those in a single repo.
But putting literally all your code in a single repo is not a very sane technical choice, is it?
- jayd16 3y agoDepends on the test tooling. If you want a single commit to pass integration tests then they need to be in a single commit. Otherwise you're tracking every version of every tool. But I like to look at the problem from another perspective. Why _not_ use a single repo. The only real reason would be to work around technical challenges with your source control of choice, not because having everything tracked together is inherently bad.
- compiler-guy 3y agoGoogle runs a single monorepo for 95% of its projects across the company. Google isn't perfect, but it's hard to argue that it isn't technically very good. One of the biggest advantages is that there is no version chasing and dependency questions. At commit X, everything works consistently. No debating about whether this or that dependency is out of sync.
- nottorp 3y ago> Our engineers generally work in small teams and interact with an even smaller subset of the monorepo. The article says. But if Google does it it must be good.