Phil Hord <phil.hord@xxxxxxxxx> 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
--
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