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.
There's absolutely zero reason to think shallow clones have *anything* to
do with this. It's a totally separate dimension. Sure, you could use
shallow clones *too*, but it has nothing to do with subprojects.
they are seperate, but if you need to compile the superproject you either need
to get the full history of every subproject, or you need shallow clones (or some
third approach).
David Lang
-
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