Re: [RFC/PATCH] add update to branch support for "floating submodules"

["Andreas T.Auer" <andreas.t.auer_gtml_37453@ursus.ath.cx>]

On 10.12.2011 16:27 Leif Gruenwoldt wrote:
>  On Sat, Dec 10, 2011 at 1:30 AM, Junio C Hamano <gitster@pobox.com>
>  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.

So you don't want to have a stale submodule as Junio suggested, which is 
older than the gitlinked commit in the superproject, but you want to 
have the newest stable version, which is not yet gitlinked in the 
superproject, right?

Wouldn't  ( cd commonlib ; git pull stable ) instead of
git submodule update commonlib
work as you want?

To be able to configure this update behavior in .gitmodules for _some_ 
submodules, could be helpful in this case.

So you don't want to add a new commit to the products A, B and C repos 
whenever the stable branch of the submodule changes, but on the other 
hand when you commit changes to the products it would still make sense 
to update the gitlink to the current commonlib version together with 
your changes,  too, right?


>  This is how package management on many linux systems works.
>  Dependencies get updated and all products reap the benefit (or
>  catastrophe) automatically.
If I have e.g. the Debian testing distro, which is more floating than 
the most other Linux distro releases, then I still get only those 
versions of the packages that are referenced by this "Debian testing" 
superproject, unless I specify a different superproject (e.g. "Debian 
unstable") to get a newer version, but they are still tracked in some 
superproject. I'm not aware of a way to get the newest version of a 
package before it is in some "superproject", except downloading it 
explictily somewhere else. But I don't think this is what you want.