What they're really for, is vendoring someone else's code into yours. They're still not great even at that, but sometimes they're the best option.
What they're really for, is vendoring someone else's code into yours. They're still not great even at that, but sometimes they're the best option.
IE is that "a" usecase or "the" usecase? I've never seen submodules used for that, only for internal dep management, so if there's content about "what they're really for," I'd love to read more.
It'd be nice to use submodules for this but I gave up years ago.
The other big use is where you have your own libraries and you'd like to be able to share them across projects. My friend does game jams and has his own simple engine, he versions the engine and adds abilities and uses it across game projects.
Vendoring usually implies some kind of snapshot-copying of third-party code. A repo you depend on by value. That's actually solved by subtrees. If you buy that metaphor, then submodules, in contrast, express a dependency by reference.
tl;dr anyone vendoring with submodules is prolly doing it wrong