From: Andreas T.Auer Date: Mon, 12 Dec 2011 15:34:05 GMT Subject: Re: [RFC/PATCH] add update to branch support for "floating submodules" Message-ID: <4EE61EED.50604@ursus.ath.cx> In-Reply-To: On 10.12.2011 16:27 Leif Gruenwoldt wrote: > On Sat, Dec 10, 2011 at 1:30 AM, Junio C Hamano > 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.