Heiko Voigt <hvoigt <at> hvoigt.net> writes: > > Hi, > > On Wed, Nov 09, 2011 at 10:01:33AM -0800, Junio C Hamano wrote: > > Heiko Voigt <hvoigt <at> hvoigt.net> writes: > > > > > This is almost ready but I would like to know what users of the > > > "floating submodule" think about this. > > > > Thanks for working on this. > > > > I do like to hear from potential users as well, because the general > > impression we got was that floating submodules is not a real need of > > anybody, but it is merely an inertia of people who (perhaps mistakenly) > > thought svn externals that are not anchored to a particular revision is a > > feature when it is just a limitation in reality. During the GitTogether'11 > > we learned that Android that uses floating model does not really have to. > > Since we did not get any reply from potential floating submodule users I > do not mind to drop this patch for now. It is archived in the mailing list > and it should be easy to revive once there is real world need for it. > > Once we have the "exact" model support for checkout and friends this > might be a handy tool to update submodules before releases and such. But > currently I would like to focus on the "exact" front first. > > Cheers Heiko > If I understand the description of "floating submodules", it's something I have been wanting for a while now! The lack of it is currently a deal breaker for using submodules within my organisation. Our use case is as follows. We have several repositories for our common code (commonA.git, commonB.git, etc) and a few different products that leverage these common repos (productA.git, productB.git, etc). When one of the products is in heavy development we often need to do a lot of work in the common repos. Having to increment the sha1 of the submodules to track the latest tip would be overly arduous. (Obviously when development of the product stabilizes we would want to change to anchoring to a specific sha1 in the common repos). -- 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