I'm mainly team monorepo because working with git submodules is such an needlessly miserable experience.
At work we have a pretty large project with many teams having moved to using nested git submodules for their stuff.
Whenever you checkout a commit you basically have do a `git submodule --init --recursive` and pray there's no random files left over because some submodule has moved and git-submodule thinks it's your job to clean up its mess. This becomes really annoying when you want to bisect something.
Surely there must be a saner way to deal with trees of git repos. I guess AOSP uses its own `repo` tool to do multirepo stuff which might be better. But honestly this _should_ be fixable in git-submodule itself if they just make it behave sanely.
By the time you have so much code that you benefit from a monorepo, you probably have so much code that you benefit from working in a statically typed language, and addressing that first will probably give you concrete benefits faster.
I would love to read more about how the author is tackling the testing problem in their setup.
At work we have a pretty large project with many teams having moved to using nested git submodules for their stuff.
Whenever you checkout a commit you basically have do a `git submodule --init --recursive` and pray there's no random files left over because some submodule has moved and git-submodule thinks it's your job to clean up its mess. This becomes really annoying when you want to bisect something.
Surely there must be a saner way to deal with trees of git repos. I guess AOSP uses its own `repo` tool to do multirepo stuff which might be better. But honestly this _should_ be fixable in git-submodule itself if they just make it behave sanely.