Re: .gitlink for Summer of Code

[David Lang <david.lang@digitalinsight.com>]

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