On Mon, Apr 22, 2019 at 7:53 PM Jonathan Tan <jonathantanmy@xxxxxxxxxx> wrote: > > > * jt/fetch-cdn-offload (2019-03-12) 9 commits > > - SQUASH??? > > - upload-pack: send part of packfile response as uri > > - fetch-pack: support more than one pack lockfile > > - upload-pack: refactor reading of pack-objects out > > - Documentation: add Packfile URIs design doc > > - Documentation: order protocol v2 sections > > - http-fetch: support fetching packfiles by URL > > - http: improve documentation of http_pack_request > > - http: use --stdin when getting dumb HTTP pack > > > > WIP for allowing a response to "git fetch" to instruct the bulk of > > the pack contents to be instead taken from elsewhere (aka CDN). > > > > Waiting for the final version. > > Sorry for getting back to you late on this. The current status is that > v2 (this version) looks good to me, except that not many people seems to > be interested in this - I sent out v2 [1] with a relatively significant > protocol change to v1 (requiring the server to also send the packfile's > hash, meaning that a workflow that Ævar has described will no longer > work), but nobody replied to it except for Josh Steadmon (who did give > his Reviewed-By). There has been no answer to my comments in: https://public-inbox.org/git/CAP8UFD3SWNu=btPxV2vV=neYrofbgKPzz_WLvsJbv6bKjRoCpQ@xxxxxxxxxxxxxx/ especially the part related to the "-o avoid-cdn=badcdn.example.com" example that Jonathan Nieder gave. [...] > If this version is good with everyone, then this is the final version. It is not good for me as I think the "-o avoid-cdn=badcdn.example.com", or even "-o usecdn=goodcdn.example.com" options, (that has been the only thing suggested to work around problems with CDNs that people cannot use or don't want to use,) will likely end up to be some other kind of promisor remote but not quite a real promisor remote. In a more general way I don't understand why I was repeatedly asked (especially by Jonathen Nieder, you and Junio) to dump ODB remotes in favor of promisor remotes because promisor remotes would be more unified, and now you develop something that is not unified with promisor remote, though it could very well be. (And you haven't yet taken the time to review the multi promisor work I did following your suggestions, though it is the first item in the future work plan you wrote in Documentation/technical/partial-clone.txt)
