Leif Gruenwoldt <leifer@xxxxxxxxx> writes: > On Sat, Dec 10, 2011 at 1:30 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> So that use case does not sound like a good rationale to require addition >> of floating submodules. > > Ok I will try another scenario :) > > Imagine again products A, B and C and a common library. The products are in > a stable state of development and track a stable branch of the common lib. > Then imagine an important security fix gets made to the common library. On > the next pull of products A, B, and C they get this fix for free > because they were > floating. They didn't need to communicate with the maintainer of the common > repo to know this. In fact they don't really care. They just want the > latest stable > code for that release branch. > > This is how package management on many linux systems works. Dependencies > get updated and all products reap the benefit (or catastrophe) automatically. Distro package dependency tracking is a poor analogy for many reasons, but I'll only touch a few. If you have a common library L and application packages A, B and C, first of all, you do not build distro package of A from the sources of A and L. Instead, package A has a build dependency on package L-devel (in other words, "in order to build A from the source, you need L-devel package installed in your build environment"), build A from its source, link it against L's binary without having the source of L. So the source code arrangement is very different from the typical submodule case, in that you do not even need to have A and L appear in the same working tree, let alone bound in a same superproject as two submodules. A library L may have two API versions, and application A and B may be written for its v1.0 and v2.0 API, respectively. Distro packaging makes the binary package A and B _know_ about their own dependency requirements by recording "A depends on L (v1.0<=,<v2.0)", "B depends on L (v2.0<=)", etc. Naively, one might think that two branches, branch-1.0 and branch-2.0, can be defined in the repository of L, tell somebody (like "superproject that covers all the packages in the distro") that A wants branch-1.0 and B wants branch-2.0 of L respectively, to emulate this, but if one thinks further, one would realize that it is insufficient. For one thing, it is unclear what should happen when both A and B are asked to be checked out, but more importantly, in dependency requirements on real distro packaging, the application C could say "I want v1.0 API but v1.4 is broken and not compatible with me", which won't fit on the two-branches model. A workaround to add more branches to L could be devised but any workaround cannot be a good solution that allows a random application C among 47 others to dictate how the branch structure of L project should look like. Fortunately, the dependency management is a solved problem by distro package management and build systems, and they do so without using anything from submodules. There is no point reinventing these logic in git submodules and emulating poorly. The only remotely plausible analogy around distro packaging would be a superproject full of all the packages in a distro as its submodules, and records exact versions of each and every package that goes on a release CD (or DVD). In that case, you do want to have a central registry that records what exact version of each package is used to cut the CD and the mother of all modules superproject could be one way to implement it. But that is not an example of floating, but is a direct opposite. This exchange convinced me further that anybody who wishes to use "floating" is better off either by doing one or both of the following: - using "exact" but not updating religiously, as the interdepency requirement in their project is not strict; or - not using submodules at all, but merely keeping these unrelated A, B, C and L as standalone repositories next to each other in the directory structure. -- 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