Re: Resumable clone

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 5, 2016, 18:40 UTC
Message-ID: <xmqqk2lgvke6.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqoaasvkrt.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 20 quoted lines

> So what remains?  Here is a rough and still slushy outline:
>
>  - A new method, prime_clone(), in "struct transport" for "git
>    clone" client to first call to learn the location of the
>    "alternate resource" from the server.
>
>    ...
>    - The format of the returned "answer" needs to be designed.  It
>      must be able to express:
>
>      - the location of the resource, i.e. a URL;
>
>      - the type of resource, if we want this to be extensible.  I
>        think we should initially limit it to "a single full history
>        .pack", so from that point of view this may not be absolutely
>        necessary, but we already know that we may want to say "go
>        there and you will find an old-style bundle file" to support
>        the kernel.org CDN, and we may also want to support Jeff's
>        "split bundle" or Shawn's ".info" file.  A resource poor
>        (read: personal) machine that hosts a personal of a popular

Sorry for a typo: s/of a/fork &/;

>        project might want to name a "git clone" URL for that popular
>        project it forked from (e.g. "Clone Linus's repository from
>        kernel.org and then come back here for incremental fetch").