Re: organizing multiple repositories with dependencies
- From
- dag@cray.com <dag@cray.com>
- Date
- Apr 30, 2012, 19:43 UTC
- Message-ID
- <nngd36pxawy.fsf@transit.us.cray.com>
- In-Reply-To
- <CABURp0pHcZfUw8p5F=7W3BipGHdc2Q0QQ7WuaPPVWOYdG1S=BQ@mail.gmail.com>
Phil Hord <phil.hord@gmail.com> writes:
Show 20 quoted lines
>> 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.
Show 14 quoted lines
> 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