4 ms·

They are very useful when you've got hundreds of engineers working on distinct projects that are loosely connected. Imagine you have a team working on core lib

They are very useful when you've got hundreds of engineers working on distinct projects that are loosely connected. Imagine you have a team working on core libraries, a few product platform teams, and finally a team working on a customer facing feature. The feature team commits to master and a build kicks off (build 1), that build fails for an unrelated issue (say the build node dies) and the build kicks off again (build 2). With multiple layers of libraries supporting the feature team, its entirely possible that a dependency could have changed and the end result of build 2 would be different than build 1. When each commit shares a common timeline it is really easy to rebuild build 1 with the exact same dependencies.

derefr 5y ago
Git submodules already solve that problem, though. As does publishing all the core libraries etc. as language-ecosystem packages on a private package namespace or internal corporate package repository, and then resolving/locking the language-package dependencies to specific tags/refs with a lockfile that gets committed to the downstream repo. These are the "obvious" solutions to this problem, the first ones the average software architect would reach for. What would lead them to ignore these options and choose a monorepo instead, if not for what I mentioned above — the ability to make atomic changes to cross-cutting concerns?
- chiefalchemist 5y ago
  I've resisted - for too long? - submodules as I've always heard they can be problematic; that the actual implementation isn't quite what I should be.
- justaguy88 5y ago
  Git submodules have an annoying attribute: double commit First you commit/push to one repository Then you update the submodule pointer in the parent repository
- zerkten 5y ago
  >> These are the "obvious" solutions to this problem, the first ones the average software architect would reach for. They would have been, except the experience working with them was somewhat problematic for those who have been down this path, and the message that many devs have received is to avoid them. I kind of agree with going to submodules, but confidence doesn't seem to have been rebuilt.

derefr 5y ago

Git submodules already solve that problem, though. As does publishing all the core libraries etc. as language-ecosystem packages on a private package namespace or internal corporate package repository, and then resolving/locking the language-package dependencies to specific tags/refs with a lockfile that gets committed to the downstream repo. These are the "obvious" solutions to this problem, the first ones the average software architect would reach for. What would lead them to ignore these options and choose a monorepo instead, if not for what I mentioned above — the ability to make atomic changes to cross-cutting concerns?

chiefalchemist 5y ago
I've resisted - for too long? - submodules as I've always heard they can be problematic; that the actual implementation isn't quite what I should be.
justaguy88 5y ago
Git submodules have an annoying attribute: double commit First you commit/push to one repository Then you update the submodule pointer in the parent repository
zerkten 5y ago
>> These are the "obvious" solutions to this problem, the first ones the average software architect would reach for. They would have been, except the experience working with them was somewhat problematic for those who have been down this path, and the message that many devs have received is to avoid them. I kind of agree with going to submodules, but confidence doesn't seem to have been rebuilt.