On Mon, Nov 09, 2020 at 01:20:14PM -0800, Junio C Hamano wrote: > Would the earlier refactoring of the negotiation part into a > separate negotiator module help, or did the refactor not remove the > deep assumption that it is only about the fetch/upload-pack traffic > and we need a design for push/receive-pack from scratch? I haven't thought too deeply about this problem area, but there is one challenge I'd expect with reusing the existing negotiation protocol and code: the stateless side is flipped for http. In the fetch protocol, the client is stateful and makes a series of requests to a stateless server, each time saying "I want X, we agreed previously on Y, and here are some more options Z; let me know if that's enough to generate a pack". If we were to flip that around, the client must remain the stateful party, but it's no longer the receiver of the pack. For the receiver (i.e., the stateless server) to iterate through its history looking for a shard point, I think the message would have to be more like "last time you told me about X, and gave me cut-points Y to resume your traversal; tell me more about Y so that I can decide if we're ready to send a pack". -Peff
