Re: [RFC/PATCH] add update to branch support for "floating submodules"
- From
Leif Gruenwoldt <leifer@gmail.com>
- Date
- Dec 12, 2011, 18:04 UTC
- Message-ID
- <CALFF=ZRYB1LkAY5WSC4Eydu-N0KNnWLLM2CfbSXZji18yO82gw@mail.gmail.com>
- In-Reply-To
- <4EE61EED.50604@ursus.ath.cx>
On Mon, Dec 12, 2011 at 10:34 AM, Andreas T.Auer <andreas.t.auer_gtml_37453@ursus.ath.cx> 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.
Show 5 quoted lines
> 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.