How to handle nested submodule dependencies

Question

I have a git repo with nested submodule dependencies (see picture as an example). There are duplications because each repo needs to be compiled standalone in a pipeline so that the corresponding test executable can be run. Currently, this is solved with submodules. If E gets a new commit, I need to

• update submodule pointer D->E from A->B->D and from A->C->B->D
• update submodule pointer B->E from A->B and from A->C->B

Which is annoying and makes cloning A take forever, because the whole B branch exists twice. How are structures with nested dependencies like this handled best? Is there an easy way to handle this with binaries?

enter image description here

• Bart van Ingen Schenau: Does A need to have the source code of B and C, or would it be good enough to have a library? What happens if B and D refer to different versions/commits of E?
• Call of Guitar: I actually found this answer to a similar post softwareengineering.stackexchange.com/questions/114719/…, they suggest having empty build repositories which seems to be the best solution
• Bart van Ingen Schenau: Does this answer your question? Organizing Git repositories with common nested sub-modules
• Greg Burghardt: Every question I see about git submodules always feels like a dependency management problem disguised as a version control problem. I feel like we could answer this question, but I think we need more information about why each submodule needs to be compiled in its own pipeline.
• Greg Burghardt: And I've always felt like submodules were a dependency management tool smooshed into a version control system that was never built with dependency management in mind.

Answer 1

You've not specified the langauge, but if the submodules are reasonably slow to change and can be versioned separately, then it may make sense to compile them and ship packages.

• pjc50: Not sure why this attracted downvotes?