> 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). Yes - and I also noticed that finish_http_pack_request() is also used in http-push.c, but I'm not familiar with that. > 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. We would have to figure out how to communicate any Git HTTP config variables to curl/wget etc. (and also declare a dependency on such a tool), but that could be done.
