Jonathan Tan <jonathantanmy@xxxxxxxxxx> 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.
