On Fri, Dec 9, 2011 at 8:41 PM, Andreas T.Auer <andreas.t.auer_gtml_37453@xxxxxxxxxxxx> wrote: >>> It is even nice to see which commits in the submodule belong to what >>> branches in the superproject or to what release version (so tracking >>> superproject tags would make sense, too). If you have a submodule that >>> has >>> more than one superproject but these are well-defined, it could be solved >>> using refspecs (e.g. refs/super/foo/* for one and refs/super/bar/* for >>> the >>> other superproject), but currently I can't think of a context where this >>> makes sense. >> >> I can, but this does put the cart before the horse. The submodule is >> subservient to the super project in all my setups. The submodule is >> not aware who owns him. He is a bit like the DAG in reverse. He >> knows one direction only (children), not the other (parents). > > In the setup I have in mind, the submodules are not subservient to the > superproject, but a part of the whole project. I see that. I have a similar project with about 20 submodules. None of them are useful on their own; they are logical divisions of a large project. Architecturally, submodules are oblivious of their super-projects in all other respects. Changing the architectural underpinnings should be a last resort, I think. Phil -- 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