Re: Tracking a repository for content instead of history

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 12, 2006, 16:24 UTC
Message-ID: <Pine.LNX.4.63.0612121715230.2807@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <200612121538.41197.andyparkins@gmail.com>

Hi,

On Tue, 12 Dec 2006, Andy Parkins wrote:

Show 23 quoted lines

> On Tuesday 2006 December 12 14:28, Johannes Schindelin wrote:
> 
> > You are not by any chance talking about the --remote option to
> > git-archive?
> 
> I wasn't; but that's certainly a helpful switch.  It's certainly a huge 
> help.
> 
> > If you want to reduce the number of objects to be downloaded, by telling
> > the other side what you have, you literally end up with something like
> > shallow clone: the other side _has_ to support it.
> 
> I suppose so; but I was thinking more an automated way of getting the data 
> that is supplied for the kernel anyway.  So:
> 
> base-v1.0.0.tar.gz
> patch-v1.0.1.gz
> patch-v1.0.2.gz
> etc
> 
> Each patch is obviously smaller than "base".  Git could easily make the 
> patches, and each of those patches could be fed by hand into a repository 
> with git-apply.

If it weren't for the recent discussion of kernel.org being overloaded with gitweb processes, I'd just write down a hint like http://repo.or.cz/w/git/jnareb-git.git?a=commitdiff_plain;h=next;hp=master

But since kernel.org is overloaded, I will not do that.

Ciao,