On Tue, 27 Mar 2007, Linus Torvalds wrote: > Think of it this way: if you think people find it a bit annoying that you > currently have to get all the history when you do clone (and why people > have worked on "shallow clones" in git), imagine just *how* frustrating it > is if you have to get all five-hundred subprojects when you only want to > work on one small one! Is it fair to say that subproject support means that there's a use case where everybody will need shallow clones? And that it points out natural triggers for shallowness? I don't see that the "shallow clone" mechanism is special for subprojects (and I don't think that a solution that depends on subprojects being what causes it is a good idea), but clearly it makes sense to support: (1) no clone of submodules, (2) shallow clone of submodules, and (3) full clone of submodules. Somebody working on gcc for *BSD would presumably want to get all of gcc and a shallow clone of the other 1000 submodules, right? Or they'd just clone the submodule and ignore the superproject. At least, they'd need shallow clones of a bunch of the submodules, because it's not interesting to have the superproject otherwise. -Daniel *This .sig left intentionally blank* - 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