Leif Gruenwoldt <leifer@xxxxxxxxx> 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. -- 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