Sharing Git Submodules

Question

I have Libraries A, B, C, and D.

the dependencies look like so:

   A
   |
  / \
B     C
 \   /
   D

However we have the B and C git repos set up with D as a submodule. we would like to setup B and C as submodules in A, but we would also like to somehow have them both point to a single submodule instance of D.

Does anyone know the right way to do this?

Answer 1

If you add B and C as submodules to A, their .git files will be stored in A under .git/modules/B and .git/modules/C. Each of those (once you've done git submodule init; git submodule update in each) will have its own .git/modules/D, however, so the repo files will not be shared. Each will have its own checked-out copy of the files as well.

You could get around these issues with symlinks. For example, you could add D as a submodule only to B, then symlink B's D in C. Now you can work in either B/D or C/D, and the other will stay in sync. There are 2 problems with this, though. The first is that you can't check out different points in each - they must stay in sync, because they're the same thing. This is minor, though, and may even match your wishes. The second is worse; if you're tracking D only in B, and C is 'tracking' it only as via symlink to B's D (symlinks are understood by git, btw), then C has no way to govern its own dependency on D.

It's normal to make a change to a submodule and then check that change in the dependent, containing repo, but now you have to remember to jump into the other repo in the diamond and make sure it works, too (automated testing - especially if run through a git hook - can help a lot here). If you revert a commit in B/D, e.g., or check out an older one, or switch branches in B/D, you have to always hop over to C/D and make sure things still work there. This setup can become a bit of a micromanagement pain, prone to broken commits, wherein B works against the current D, but C doesn't, or vice-versa.