From: dag@cray.com
Date: Mon, 30 Apr 2012 19:43:57 GMT
Subject: Re: organizing multiple repositories with dependencies
Message-ID: <nngd36pxawy.fsf@transit.us.cray.com>
In-Reply-To: <CABURp0pHcZfUw8p5F=7W3BipGHdc2Q0QQ7WuaPPVWOYdG1S=BQ@mail.gmail.com>

Phil Hord <phil.hord@gmail.com> writes:

>> 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