Re: [PATCH 00/11] Resumable clone

Junio C Hamano wrote: > Eric Wong writes: > > >> [primeclone] > >>url = http://location/pack-$NAME.pack > >>filetype = pack > > > > If unconfigured, I wonder if a primeclone pack can be inferred by > > the existence of a pack bitmap (or merely being

Re: [PATCH 00/11] Resumable clone

Junio C Hamano writes: > Junio C Hamano writes: > > What "git clone" should have been was: > > * Parse command line arguments; > > * Create a new repository and go into it; this step would > require us to have parsed the command line for

Re: [PATCH 00/11] Resumable clone

Junio C Hamano writes: >>> git clone --resume >> >> I think calling "git fetch" should resume, actually. >> It would reduce the learning curve and seems natural to me: >> "fetch" is jabout grabbing whatever else appeared since the >> last clone/fetch happened. > > I hate say

Re: [PATCH 00/11] Resumable clone

Eric Wong writes: >> [primeclone] >> url = http://location/pack-$NAME.pack >> filetype = pack > > If unconfigured, I wonder if a primeclone pack can be inferred by > the existence of a pack bitmap (or merely being the biggest+oldest > pack for dumb HTTP). That would

Re: [PATCH 00/11] Resumable clone

Kevin Wern wrote: > Hey, all, > > It's been a while (sent a very short patch in May), but I've > still been working on the resumable clone feature and checking up on > the mailing list for any updates. After submitting the prime-clone > service alone, I figured

Re: [PATCH 00/11] Resumable clone

Kevin Wern writes: > It's been a while (sent a very short patch in May), but I've > still been working on the resumable clone feature and checking up on > the mailing list for any updates. After submitting the prime-clone > service alone, I figured implementing the whole