Re: Make "git clone" less of a deathly quiet experience

From: Eric W. Biederman <ebiederm@xmission.com>
Date: Feb 16, 2006, 06:56 UTC
Message-ID: <m1ek23rduh.fsf@ebiederm.dsl.xmission.com>
In-Reply-To: <43EF15D1.1050609@op5.se>

Andreas Ericsson <ae@op5.se> writes:

Show 14 quoted lines

> Keith Packard wrote:
>> On Sun, 2006-02-12 at 04:43 +0100, Andreas Ericsson wrote:
>>
>>>A weird oddity; Cloning is faster over rsync, day-to-day pulling is not.
>> Precisely. If the protocol could deliver existing packs instead of
>> unpacking and repacking them, then git would be as fast as rsync and I
>> wouldn't have to worry about supporting two protocols.
>>
>
> Caching features have been discussed, but that means the daemon needs to have
> write-access to some directory within the repository. It would also work poorly
> for projects that see very rapid development unless the cached pack-files can be
> amended to. A sort of "create packs on demand". It shouldn't be too difficult,
> really.

Actually for the clone case we don't need a writable directory for the git-daemon.

If we assume that a repository up for download is reasonably packed, we can just lob all of the packs in the current repository, and then pack the few remaining objects and send them.

I don't know how well multiple packs will work with the current git protocol but it should be pretty natural, and the clone case is easy detect as there are no heads in common. Can that be detected quickly?

I don't have a patch but it feels like a pretty straight forward thing to implement.

Eric