Re: organizing multiple repositories with dependencies

Phil Hord [off-list ref] writes:

quoted

I can't think of a situation where I would need to implement the same
or similar features in multiple components where those components are
not tightly coupled in some way.

I tend to agree.  However, I have a use case that I suffer on a daily basis.

We have code that runs on multiple platforms (embedded SoCs).  I have
a superproject that has a common library and some vendor-specific code
for each supported platform broken out into submodules.

  super-all
    +-- CommonAPI
    +-- VendorA
    +-- VendorB
    +-- VendorC

The code in the Vendor submodules contains the proprietary
implementations for specific vendor's systems of the CommonAPI
library.  When the CommonAPI gets a new feature, it often gets
implemented in all the vendor submodules as well.

Ah yes, that's a good example.

We could easily do this without submodules, of course.  But this setup
allows us to define alternative super-projects that we can then share
with subcontractors and original vendors without exposing proprietary
third-party code.

  super-B
    +-- CommonAPI
    +-- VendorB

  super-C
    +-- CommonAPI
    +-- VendorC

We could still handle this with git-subtree.  But we don't.

Yes, I agree that this is a very important use case.  This is the case
where subprojects exist because of vendor barriers, not necessarily due
to software engineering concerns.

                                  -Dave