Subject: Re: [PATCH] fetch-pack: do not mix --pack_header and packfile uri

From: Junio C Hamano <[email-masked]>
Date: Wed, 10 Mar 2021 17:41:16 -0800

Jonathan Tan <[email-masked]> writes:

> This probably means that fetch-pack.c itself (instead of
> finish_http_pack_request(), currently being called from a separate
> http_fetch process) should call index-pack for the out-of-band
> packfiles, which is conceptually reasonable. This means that
> finish_http_pack_request() will need to be able to refrain from running
> index-pack itself and instead just return where the pack was downloaded.

The HTTP downloading for packfile specified via the packfile URI
mechansim is so different from the rest of the HTTP codepaths in
nature, isn't it?  It is a straight "download a static file over the
web, and we could even afford to resume, or send multiple requests
to gain throughput" usecase, which does not exist anywhere else in
Git (eh, other than the dumb HTTP protocol nobody sane should be
using anymore).

Since we are not in the business of writing a performant HTTP
downloader, if we can update the codepath not to rely on our http.c
code, and instead spawn one of the command line tools written
specifically for the "download a single large file over HTTP"
usecase (like curl, wget or aria2c), wait for it to do its thing and
then concentrate on the processing specific to Git (like running
index-pack with various options), it would take us closer to the
"make clone resumable" dream, wouldn't it?

Thanks.