Re: organizing multiple repositories with dependencies

From: Phil Hord <phil.hord@gmail.com>
Date: Apr 30, 2012, 19:25 UTC
Message-ID: <CABURp0pHcZfUw8p5F=7W3BipGHdc2Q0QQ7WuaPPVWOYdG1S=BQ@mail.gmail.com>
In-Reply-To: <nngd36w1z9n.fsf@transit.us.cray.com>

On Tue, Apr 24, 2012 at 7:33 PM,  <dag@cray.com> wrote:

Show 15 quoted lines

> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
>>> No, I think that is actually very rare.  If topic branches really should
>>> be mirrored then U and S should be one repository.  They are too closely
>>> coupled to be separated.  But see the but about git-subtree and topic
>>> branches below.
>>
>> Too closely coupled? I do not think breaking up a project into a set
>> of libraries makes everything tightly coupled. I would argue the
>> opposite. :-) Anyway, you answer my concern below.
>
> If you need the same topic branch for each component they would indeed
> seem to be very tightly coupled, even if the code is "physically"
> separated.  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.

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.

Phil