Re: .gitlink for Summer of Code
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Mar 27, 2007, 23:31 UTC
- Message-ID
- <euc9av$2p9$1@sea.gmane.org>
- In-Reply-To
- <Pine.LNX.4.63.0703271245580.15345@qynat.qvtvafvgr.pbz>
David Lang wrote:
Show 32 quoted lines
> 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