Re: Features from GitSurvey 2010

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Feb 1, 2011, 17:11 UTC
Message-ID: <AANLkTi=_DPSp2P3MuFOPgua2nH7U+RUt4AfAHSyPVv-G@mail.gmail.com>
In-Reply-To: <AANLkTinPAL2rEUMe-tRGFxSQ0-gfAJvSO7WW+f+2Fd2u@mail.gmail.com>

On Tue, Feb 1, 2011 at 11:27 PM, Shawn Pearce <spearce@spearce.org> wrote:

Show 21 quoted lines

> On Tue, Feb 1, 2011 at 05:51, Jakub Narebski <jnareb@gmail.com> wrote:
>>
>>> > resumable clone/fetch (and other remote operations)
>>>
>>> Jakub Narebski seems to be interested in this and Nicolas Pitre has
>>> given some good advice about it.  You can get something usable today
>>> by putting up a git bundle for download over HTTP or rsync, so it is
>>> possible that this just involves some UI (porcelain) and documentation
>>> work to become standard practice.
>>
>> I wouldn't say that: it is Nicolas Pitre (IIRC) who was doing the work;
>> I was only interested party posting comments, but no code.
>>
>> Again, this feature is not very easy to implement, and would require
>> knowledge of git internals including "smart" git transport ("Pro Git"
>> book can help there).
>
> I think Nico and I have mostly solved this with the pack caching idea.
>  If we cache the pack file, we can resume anywhere in about 97% of the
> transfer.  The first 3% cannot be resumed easily, its back to the old
> "git cannot be resumed" issue.  Fixing that last 3% is incredibly

I thought the cached pack contained anything and for initial clone, we simply send the pack. What is this 3%? Commit list? Initial commit?

> difficult... but resuming within the remaining 97% is a pretty simple
> extension of the protocol.  The hard part is the client side
> infrastructure to remember where we left off and restart.

Narrow/Subtree clone is still just an idea, but can pack cache support be made to resumable initial narrow clone too?

-- 
Duy