Re: Resumable clone

Junio, > Yes, that is very close to what I said in the "what remains?" > section, but with a crucial difference in a detail. Perhaps reading > the message you are respoinding to again more carefully will clear > the confusion. This is what we want to allow the server to say > (from the message

Re: Resumable clone

Duy Nguyen writes: > Yeah the determination is tricky, it depends on server setup. Let's > start with select the pack for download first because there could be > many of them. A heuristic (*) of choosing the biggest one in > $GIT_DIR/objects/pack is probably ok for now (we

Re: Resumable clone

Kevin Wern writes: > From what I understand, a pattern exists in clone to download a > packfile when a desired object isn't found as a resource. In this > case, if no alternative is listed in http-alternatives, the client > automatically checks the pack index(es) to see

Re: Resumable clone

On Tue, Mar 8, 2016 at 10:33 AM, Kevin Wern wrote: > Hey Junio and Duy, > > Thank you for your thorough responses! I'm new to git dev, so it's > extremely helpful. > >> - The server side endpoint does not have to be, and I think it >> should not be, implemented as an

Re: Resumable clone

Hey Junio and Duy, Thank you for your thorough responses! I'm new to git dev, so it's extremely helpful. > - The server side endpoint does not have to be, and I think it > should not be, implemented as an extension to the current > upload-pack protocol. It is perfectly fine to add a new "git >

Re: Resumable clone

Johannes Schindelin writes: > First of all: my main gripe with the discussed approach is that it uses > bundles. I know, I introduced bundles, but they just seem too klunky and > too static for the resumable clone feature. We should make the mechanism extensible so

Re: Resumable clone

Duy Nguyen writes: > One thing Junio didn't mention in his summary is the use of pack > bitmap [1]. Jeff talked about GitHub specific needs,... Do not take it as the "summary of the whole discussion". I deliberately tried to limit the list to absolute minimum to allow

Re: Resumable clone

On Sun, Mar 6, 2016 at 3:49 PM, Duy Nguyen wrote: > One thing Junio didn't mention in his summary is the use of pack > bitmap [1]. > > [1] http://thread.gmane.org/gmane.comp.version-control.git/288205/focus=288222 Oops, wrong link. Should be this one

Re: Resumable clone

On Sun, Mar 6, 2016 at 2:59 PM, Johannes Schindelin wrote: > First of all: my main gripe with the discussed approach is that it uses > bundles. I know, I introduced bundles, but they just seem too klunky and > too static for the resumable clone feature. One thing

Re: Resumable clone

Hi Junio & Duy, On Sat, 5 Mar 2016, Junio C Hamano wrote: > Duy Nguyen writes: > > > Resumable clone is happening. See [1] for the basic idea, [2] and [3] > > for some preparation work. I'm sure you can help. Once you've gone > > through at least [1], I think you can pick

Re: Resumable clone

Junio C Hamano writes: > 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. > >... >-

Re: Resumable clone

Duy Nguyen writes: > Resumable clone is happening. See [1] for the basic idea, [2] and [3] > for some preparation work. I'm sure you can help. Once you've gone > through at least [1], I think you can pick something (e.g. finalizing > the protocol, update the server side, or

Re: Resumable clone

On Sat, Mar 5, 2016 at 4:23 PM, Kevin Wern wrote: > Hey, all, > > A while ago, I noticed that if a clone is interrupted, it has to be > restarted completely. When I looked up the issue, I saw that someone > suggested resumable clones as a feature as early as 2007. It