We need to track large external projects (buildroot, the Linux kernel for instance) so the ability to include them as submodules and update them fairly easily is worth it IMO. If you're at the scale of Google it probably makes vastly more sense just including the code in your monorepo and pay a bunch of engineers to merge back and forth with upstream and have the rest of your team not worry about it, but for us it would take a lot of time and effort to maintain a clone of these projects in a bespoke repository.
Re:Eden
by CorrectHorseBat on Wednesday April 13, 2022 @04:57AM
(#31012498)
We have customer IP that not everyone is allowed to access and has to be deleted after the project is done. We use submodules and IMO it sucks but I don't see a way around it considering the restrictions.
For extremely small companies (N == 1) git submodules can be neat though. Itβs a great way to create small libs without having to bother distribution through LuaRocks, npm, RubyGems and the like.
My last place was about 10 years young, 150 engineers, and was still working within a single git repo without submodules.
There is a non-zero amount of discoverable config that goes into managing a repo like that, but it's trivial compared to the ongoing headaches of managing submodules, like you suggest.