On Fri, 1 Dec 2006, Josef Weidendorfer wrote: > > > > 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 No. I would say that it looks more like a "partial checkout" than a shallow clone. A shallow clone limits the data in "time" - we have _some_ data, but we don't have all of the history of that data. In contrast, a submodule that we don't fetch is an all-or-nothing situation: we simply don't have the data at all, and it's really a matter of simply not recursing into that submodule at all - much more like not checking out a particular part of the tree. So if a shallow clone is a "limit in time", a lack of a module (or a lack of a checkout for a subtree in general - you could certainly imagine doing the same thing even _within_ a git repository, and indeed, we did discuss exactly that at one point in time) is more of a "limit in space". Linus - 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