On Friday 01 December 2006 21:13, Linus Torvalds wrote: > > There seems to be some agreement to store the commit id of > > the submodule instead of a plain tree id in the supermodules tree object, and > > that all objects that are reachable from this commit are made part of the > > supermodule repository (either fetched or via alternates). Do you agree? > > Well, I would actually argue that you may often want to have a supermodule > and then at least have the _option_ to decide to not fetch all the > submodules. If you want to allow this, you have to be able to cut off fetching the objects of the supermodule at borders to given submodules, the ones you do not want to track. With "border" I mean the submodule commit in some tree of the supermodule. This looks a little bit like a shallow clone, where you introduce graft points at the border to some of the submodule's object DAGs. But I am not sure that this is scalable: for supermodules with a large number of submodules you are not interested in, your graft file would grow very fast, as there will be new borders with every change in some submodule, which happens to be tracked in the supermodule. So IMHO, instead of a huge graft file, you want to have a fast way to check at a submodule border which submodule this given border is going into. Then, at fetch time, you easily can decide that you do not want to fetch any object from the submodule. Otherwise, you would have to ask the remote end at cloning time: "Is this commit from some submodule I am locally not interested in?" So I think we should introduce a submodule namespaces in supermodules. And at every border from super- to submodules, the name of the submodule we are going into should be specified. Which actually means that we need to introduce a "submodule" object, and trees of a supermodule can have such submodule objects as borders into a submodule. In a submodule object, of course we have the SHA1 of the commit into the submodule DAG, and there would be the global unique name we have choosen for this submodule in this supermodule. Something like submodule: gcc commit: 6287376... Before cloning a supermodule, you should be able to list the names of the submodules available, and select the submodules you want to have cloned together with the supermodule. > Ie, you very much should be able to to do > > git clone supermodule/that/one/submodule > my-own-version-of-submodule > > to clone a submodule _without_ getting anything else (but still get all > the work you did within he submodule - very much including your own > private branch work). So in the example, "that/one/submodule" is _not_ the path of the working tree which happens to be the root of the submodule at current supermodule HEAD, but the unique name from the submodule namespace. This is important, as you should be able to move the root of a submodule inside of your supermodule like moving any other file or directory. I.e. for every supermodule commit, the path to the root directory of a given submodule can change, making it useless as a name for a submodule selection at clone time. Josef - 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