Re: [PATCH 00/11] Resumable clone

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 27, 2016, 22:07 UTC
Message-ID: <xmqqshslkndk.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160927215143.GA32622@starla>

Eric Wong <e@80x24.org> writes:

Show 7 quoted lines

>> [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 probably be a nice heuristics but it is unclear who should find that out at runtime. The downloading side would not have a visiblity into directory listing.

Show 6 quoted lines

>> git clone --resume <resumable_work_or_git_dir>
>
> 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 this but it sounds to me like a terrible idea. At that point when you need to resume, there is not even ref for "fetch" to base its incremental work off of. It is better to keep the knowledge of this "priming" dance inside "clone". Hopefully the original "clone" whose connection was disconnected in the middle would automatically attempt resuming and "clone --resume" would not be as often as needed.