4 ms·
There are definitely a few drawbacks. For one GitHub is actually designed around a monolithic repository mindset, may be because it's all built on Rails :) whic
by ianstormtaylor 12y ago
There are definitely a few drawbacks. For one GitHub is actually designed around a monolithic repository mindset, may be because it's all built on Rails :) which means that it gets harder to find things. So we needed to build directories for finding stuff, since no good option exists.
There's also an interesting balance for things that technically should be their own repository, but shouldn't for workflow reasons since it actually means they will be more quality if they are grouped and updated at the same time. Where splitting things out can actually discourage updating if the cost is too high.
There's also a big open question around what should be a separate repository, and what is separation just for separation's sake? A similar kind of question that has to be answered for individual functions in a codebase. We've made the wrong call sometimes and split things out that should have really been together.
I tend to think that the drawbacks are worth it, since it means things are actually decoupled and generally more parts of the codebase are able to get to a "finished" state. Lots of the modules we've built haven't been touched in months or years now since they do exactly what they need to do without any bugs now.
In general I think that in programming we talk a lot about building things that are decoupled and simple, but we haven't invested anywhere near enough in tooling to quell the drawbacks to things being more spread out. The pros are extremely valuable, and the cons are solvable, we just haven't done anything about it.