Re: [ANNOUNCE] Git Merge Contributor Summit topic planning

> For instance, if the server knew that XYZ meant
>
>   - send bytes m through n of packfile p, then...
>   
>   - send the object at position i of packfile p, as a delta against the
>     object at position j of packfile q
>
>   - ...and so on
>
> Then you could store very small "instruction sheets" for each XYZ that
> rely on the data in the packfiles. If those packfiles go away (e.g., due
> to a repack) that invalidates all of your current XYZ tags. That's OK as
> long as this is an optimization, not a correctness requirement.

>> So in the real life, I think that the exchange needs to be more
>> like this:
>> 
>>     C: I need a packfile with this want/have
>>     ... C/S negotiate what "have"s are common ...
>>     S: Sorry, but our negitiation indicates that you are way too
>>        behind.  I'll send you a packfile that brings you up to a
>>        slightly older set of "want", so pretend that you asked for
>>        these slightly older "want"s instead.  The opaque id of that
>>        packfile is XYZ.  After getting XYZ, come back to me with
>>        your original set of "want"s.  You would give me more recent
>>        "have" in that request.  
>>     ... connection interrupted ...
>>     C: It's me again.  I have up to byte N of pack XYZ
>>     S: OK, resuming (or: I do not have it anymore, start from scratch)
>>     ... after 0 or more iterations C fully receives and digests XYZ ...
>> 
>> and then the above will iterate until the server does not have to
>> say "Sorry but you are way too behind" and returns a packfile
>> without having to tweak the "want".
>
> Yes, I think that is a reasonable variant. The client knows about
> seeding, but the XYZ conversation continues to happen inside the git
> protocol. So it loses flexibility versus a true CDN redirection, but it
> would "just work" when the server/client both understand the feature,
> without the server admin having to set up a separate bundle-over-http
> infrastructure.