Re: .gitlink for Summer of Code
- From
- David Lang <david.lang@digitalinsight.com>
- Date
- Mar 27, 2007, 23:20 UTC
- Message-ID
- <Pine.LNX.4.63.0703271514140.15345@qynat.qvtvafvgr.pbz>
- In-Reply-To
- <euc9av$2p9$1@sea.gmane.org>
On Wed, 28 Mar 2007, Jakub Narebski wrote:
Show 11 quoted lines
>> 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.
Ok I can see the difference in the definition of the two, the ideal would probably be to have sparse and shallow clones be different instances of the same mechanism.
sparse being specific points in the history, shallow being a range.
allow for multiple ranges, and the ability to 'fill in the blanks' later so that points can become ranges and ranges can merge.
also having the server say 'it would only be XMB more to pull everything you don't have, do you want to do this?' would cause more load on the server for each of the partial pulls, but would encourage people to fill out partial repositories instead of hitting the servers repeatedly.
David Lang