1

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

Call of Guitar
  • 19
  • 2
  • 1
    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? – Bart van Ingen Schenau Mar 07 '24 at 14:08
  • I actually found this answer to a similar post https://softwareengineering.stackexchange.com/questions/114719/organizing-git-repositories-with-common-nested-sub-modules/326016#326016, they suggest having empty build repositories which seems to be the best solution – Call of Guitar Mar 08 '24 at 11:09
  • 1
    Does this answer your question? Organizing Git repositories with common nested sub-modules – Bart van Ingen Schenau Mar 08 '24 at 12:24
  • 1
    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 Mar 09 '24 at 02:18
  • 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. – Greg Burghardt Mar 09 '24 at 02:20
  • Are these submodules used by other teams or applications, or just your own? – Greg Burghardt Mar 09 '24 at 02:36
  • Most submodules are used across several projects. To avoid too many MRs we created an "A"-branch for projects B, C, D and E. If a problem in A causes changes in a submodule, only one MR for A is created containing the changed pointers of the submodule tree. This causes diverging branches in the submodules which is not ideal, but we don't know any better. Language is C++, a change in a submodule triggers a pipeline that compiles and runs the test executable, so in theory the binaries of the dependencies would suffice – Call of Guitar Mar 10 '24 at 18:01
  • @GregBurghardt Any suggestions? Otherwise I think going with empty build repositories is the way to go – Call of Guitar Mar 11 '24 at 09:11
  • By "MR" do you mean "maintenance request?" – Greg Burghardt Mar 11 '24 at 12:03
  • Also, please [edit] your question to clarify it rather than respond in comments. – Greg Burghardt Mar 11 '24 at 12:04

1 Answers1

-2

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
  • 13,377
  • 1
  • 31
  • 35