Subject: Re: .gitlink for Summer of Code

From: Jakub Narebski <[email-masked]>
Date: Wed, 28 Mar 2007 01:31:41 +0200

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