3 ms·
If your company is small, I don't think you should be using git submodules at all. My last place was about 10 years young, 150 engineers, and was still working
by gen220 5y ago
If your company is small, I don't think you should be using git submodules at all.
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.
- wsc981 5y agoFor 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.
- CorrectHorseBat 5y agoWe 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.
- saagarjha 5y agoSubmodules are a great way to break out libraries in a language-agnostic way without having them really be broken out. This is independent of team size.
- simias 5y agoWe 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.