Re: Tracking a repository for content instead of history

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, 12 Dec 2006, Andy Parkins wrote:

> 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,
Dscho
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]