David Lang wrote: > On Tue, 27 Mar 2007, Linus Torvalds wrote: > >> On Tue, 27 Mar 2007, Daniel Barkalow wrote: >>> >>> 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? >> >> I don't see what the confusion is about. >> >> Why would you want a shallow clone, and what does that have to do with >> submodules? >> >> I'm saying that the *normal* case is that of the thousands of submodules, >> you generally care about one or two (the ones you work on). >> >> Those modules you want full history for. The supermodule you want because >> it contains the build infrastructure. You'd generally want full history >> for that too. > > if you are working on the submodule then you are correct. > > however if you are working on the supermodule it's a different story. > > if I'm working on the 'ubuntu superproject' it would be nice to be able to find > what is different between the 'Jan 2007' and 'April 2007' versions. one could > have the 2.6.19 kernel and the other would have 2.6.20. I don't care about all > the individual changes between these two states of the kernel, but I need to be > able to compile either one as part of my testing. If I bisect the in the > superproject to the commit that updated the kernel, then I would consider > getting the 'kernel subproject' history to be able to bisect the bug further (or > I may just report it to the kernel maintainers for them to check. I'd rather call this idea _sparse_ clone (not shallow), as you have only some points in the history, but they don't need to be top 'n' ones. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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