Re: [RFC 0/4] Implementation of fetch-blobs and fetch-refs

Sorry for not paying attention to this patch set earlier. I missed
(and might still
miss) the big picture(tm) here. This is because
http://public-inbox.org/git/ffd92ad9-39fe-c76b-178d-6e3d6a425037@google.com/
seemed to be specific for big binary files, but ...

On Mon, Apr 10, 2017 at 1:46 PM, Jonathan Tan [off-list ref] wrote:

In particular, patch 1 demonstrates that a new server endpoint that
serves refs without the initial ref advertisement can be done in 228
lines of code (according to "git diff --stat") while accounting for the
various special cases that upload-pack imposes (stateless RPC, inclusion
of an additional response when depth is requested, handling of "done" in
request, sending a packfile directly after a response containing "ACK
ready" without waiting for "done", and so on).

... from looking at the patches, this actually implements the idea
that was thrown around on the mailing list as "client speaks first",
as this essentially omits the refs advertisement, and then continues the
conversation by running upload-pack as normal.

That seems very exciting to me!

To that end, I'm sending these patches in the hope of showing that these
features are useful (omitting ref advertisements help greatly when
serving large repos, as described in the commit message of patch 1, and
serving blobs is useful for any fetch-blob-on-demand repo scheme) and
that my proposed way of implementing them can be done in a relatively
uncomplicated manner (as seen in these patches).

Yes, if we encapsulate v1 protocol on (both?) sides, we seem to need
very little additional code, but get the benefit of using lots of well
tested code.

Thanks,
Stefan