On Sat, Dec 10, 2011 at 9:27 AM, Leif Gruenwoldt <leifer@xxxxxxxxx> wrote:
> On Sat, Dec 10, 2011 at 1:30 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
>> So that use case does not sound like a good rationale to require addition
>> of floating submodules.
>
> Ok I will try another scenario :)
>
> Imagine again products A, B and C and a common library. The products are in
> a stable state of development and track a stable branch of the common lib.
> Then imagine an important security fix gets made to the common library. On
> the next pull of products A, B, and C they get this fix for free
> because they were
> floating. They didn't need to communicate with the maintainer of the common
> repo to know this. In fact they don't really care. They just want the
> latest stable
> code for that release branch.
>
> This is how package management on many linux systems works. Dependencies
> get updated and all products reap the benefit (or catastrophe) automatically.
What happens if the update to the floating submodule introduces a bug
that prevents A, B, and/or C from building/running correctly? If the
submodule states are not recorded, how would the previously working
submodule version be restored so that development on A, B, and C,
could proceed? I guess each developer could manually checkout @{1} in
the submodule in their working directory, though that wouldn't work
for a new clone, and it's not very elegant.
I presume that if A, B, and C, do not care to know exactly what was
fixed in the common library, they probably do not care to investigate
the breakage in that repo either. Or, they may not have the
expertise.
-Brandon
--
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