From: Nguyen Thai Ngoc Duy Date: Tue, 01 Feb 2011 17:11:56 GMT Subject: Re: Features from GitSurvey 2010 Message-ID: In-Reply-To: On Tue, Feb 1, 2011 at 11:27 PM, Shawn Pearce wrote: > On Tue, Feb 1, 2011 at 05:51, Jakub Narebski 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