On 10.12.2011 16:27 Leif Gruenwoldt 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.
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.
--
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