On Mon, Dec 12, 2011 at 10:34 AM, Andreas T.Auer <andreas.t.auer_gtml_37453@xxxxxxxxxxxx> wrote: > 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? Right. > Wouldn't ( cd commonlib ; git pull stable ) instead of > git submodule update commonlib > work as you want? Yes that's how we perform business now. > To be able to configure this update behavior in .gitmodules for _some_ > submodules, could be helpful in this case. Yes my thoughts exactly. > 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? Hmm I supose that does make sense. If the commonlib version was auto recorded during a commit of the product it would be nice. Then if/when the user reconfigured the submodule from "floating" to "strict" mode it would then have a submodule sha1 reference. I like how this sounds. -- 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