Re: [RFC/PATCH] add update to branch support for "floating submodules"

[Leif Gruenwoldt <leifer@gmail.com>]

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).