Subject: Re: [PATCH 00/11] Resumable clone

From: Junio C Hamano <[email-masked]>
Date: Tue, 27 Sep 2016 15:07:35 -0700

Eric Wong <[email-masked]> 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 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.

>> 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.