On Tue, Apr 24, 2012 at 7:33 PM, <dag@xxxxxxxx> wrote:
> Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html