Re: Git-aware HTTP transport

From: david@lang.hm <david@lang.hm>
Date: Aug 26, 2008, 03:59 UTC
Message-ID: <alpine.DEB.1.10.0808252052350.29665@asgard.lang.hm>
In-Reply-To: <20080826034544.GA32334@spearce.org>

On Mon, 25 Aug 2008, Shawn O. Pearce wrote:

Show 10 quoted lines

> "H. Peter Anvin" <hpa@zytor.com> wrote:
>> So don't implement things as GET requests unless you genuinely can deal
>> with the request being cached.  Using POST requests throughout seems
>> like a safer bet to me; on the other hand, since the only use of GET is
>> obtaining a list of refs the worst thing that can happen, I presume, is
>> additional latency for the user behind the proxy.
>
> This is a good point.  There is probably not any reason to cache the
> refs content if we don't also support caching the pack files.  So in
> this latest draft I have moved the ref listing to also be a POST.

on the other hand, it would be a good thing if pack files could be cached.

in a peer-peer git environment the cache would not be used very much, but when you have a large number of people tracking a central repository (or even a pseudo-central one like the kernel) you have a lot of people upgrading from one point to the next point.

and for cloneing (and especially thing like linux-next where you essentially re-clone daily) letting the pack get cached is probably a very good thing.

I know it would be another round-trip, but how painful would it be to compute what the contents of a pack would be (what objects would be in it, not calculating the deltas nessasary for a full pack file), and return that to the client so that the client could do a GET for the pack itself.

if that exact pack happens to be in the cache, great, if not the server takes the data from the client and creates a pack file with those objects in it.

David Lang