You have to tediously git submodule update --init--recursive every time you checkout a commit. There’s an option to do it automatically but it’s super buggy and will break your .git directory.
Switching between branches that have different sets of submodules doesn’t really work. Git won’t remove/recreate the submodules like it will for normal directories. Worst case is changing a directory to a submodule or vice versa.
If you’re working on a feature that spans several submodules you have to switch branches in all of them instead of once.
Making co-dependant changes across submodules is a nightmare.
If you’re using submodules for first party code (not uncommon), it basically creates a new public interface where you didn’t have one before. Now you have to worry about backwards compatibility and testing becomes much harder. Monorepos don’t have that problem.
The list goes on… Some of them depend on exactly what you’re using them for.
The slightly frustrating thing is that there isn’t a great answer for what to use instead. Git subtree has its own problems. Language-specific package managers do too. There aren’t any good languages agnostic package managers I know of.
I’m really hoping Jujutsu will come up with a better solution because it is possible. But it’s hard, and they are constrained by Git compatibility so I won’t hold my breath.
Yeah I’ve seen Nix and Guix suggested but they seem like a huge extra layer of complexity.
Also, strict backwards compatibility in APIs is totally worth it. It makes developing larger systems so much easier.
Usually not for first party code. It adds extra maintenance burden for little benefit.
For example suppose you want to add an extra parameter to a function. In a monorepos you just do that and fix all the compilation errors. Send one PR through CI. Job done.
With submodules… You have to add a new function so it’s backwards compatible. Deal with a default value for the old call, maybe add a deprecation warning. Oh and you need to version your library now. Then good luck finding all the places that function is called and updating them…
git submodule update --init --recursiveevery time you checkout a commit. There’s an option to do it automatically but it’s super buggy and will break your.gitdirectory.The list goes on… Some of them depend on exactly what you’re using them for.
The slightly frustrating thing is that there isn’t a great answer for what to use instead. Git subtree has its own problems. Language-specific package managers do too. There aren’t any good languages agnostic package managers I know of.
I’m really hoping Jujutsu will come up with a better solution because it is possible. But it’s hard, and they are constrained by Git compatibility so I won’t hold my breath.
Packaging libraries with Guix is a great solution.
Also, strict backwards compatibility in APIs is totally worth it. It makes developing larger systems so much easier.
Yeah I’ve seen Nix and Guix suggested but they seem like a huge extra layer of complexity.
Usually not for first party code. It adds extra maintenance burden for little benefit.
For example suppose you want to add an extra parameter to a function. In a monorepos you just do that and fix all the compilation errors. Send one PR through CI. Job done.
With submodules… You have to add a new function so it’s backwards compatible. Deal with a default value for the old call, maybe add a deprecation warning. Oh and you need to version your library now. Then good luck finding all the places that function is called and updating them…