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

[Junio C Hamano <gitster@pobox.com>]

Leif Gruenwoldt <leifer@gmail.com> writes:

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

Nobody forces you to update the commit in the submodule bound to the
superproject tree every time you update areas that are unrelated to or
independent from that frequently updated submodule.

During the period the submodule is so often updated that you feel "having
to increment ... would be overly arduous", it does not matter which exact
commit in that submodule is used in the tree for your other modules and
the superproject. Otherwise you _would_ want to say something like "for
this entire tree state from the top-level superproject to correctly work,
we absolutely need to have this commit, not any commit that is older and
is known to be broken, from this submodule", and cannot afford to use
floating.

Which means by definition anybody who wants floating can instead let such
an often updated submodule stay somewhat stale by not running "submodule
update" for it unnecessarily.  In a well-modularized set of projects, the
interface to the busy submodule may be stable and I can imagine that kind
of arrangement would well be not just possible but practical, and probably
yours may be such a project.

So that use case does not sound like a good rationale to require addition
of floating submodules.