On Tue, 27 Mar 2007, Linus Torvalds wrote: > On Tue, 27 Mar 2007, Daniel Barkalow wrote: > > > > 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? > > No. > > I personally don't believe in shallow clones. And I *certainly* don't > believe that it has anything to do with subprojects. So people may want > shallow clones, but it's at least independent of the issue of submodules. > > With subprojects, it's not that you don't want the history. It's just that > you don't want the history for *all* projects. Most people care about a > very small subset. Are you talking about submodule history, or submodule state? If they care about any state but not the corresponding history, they need to do a shallow clone of the subproject, right? Or are you assuming that people only want to have every subproject either there with full history or entirely absent? I think that one common thing would be to care about the sequence of linux kernel snapshots selected by openembedded in their commits, without caring about the linux kernel history in between those snapshots. And they probably even want to bisect the superproject (still without getting into kernel versions that were never in superproject commits), so they can track down what caused their PDA to stop booting, where it's not clear which program is even responsible. Maybe once the bug is down to a single superproject commit, they'd want the history for the responsible subproject. In any case, I think that the superproject object database needs to keep track of where references came from (e.g., if you pull somebody's superproject commit, and the point of that commit is to use a custom-modified subproject commit, that subproject commit must come from the same person, and you need to be able to fetch it correctly after the fact if you don't get it immediately, even if you've personally forgotten the URL). > (The exception, of course, is when the superproject simply isn't that big, > and only has a couple of subprojects. In git, for example, the xdiff stuff > could be a subproject if you wanted to do it that way. But then, the > subproject isn't a size issue, it's purely an organizational thing, and > there is no argument for/against shallowness there either). Of course. And to make this use case also viable, it's probably necessary to be able to tell git to fetch these subprojects automatically, because you'll be sad if you leave for a long plane trip with the latest git but not the xdiff it uses. (Clearly an application for .gitattributes, but that'd be extra fun to implement.) -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