> For a real implementation, I think we'd want to do the negotiation > inside the conversation between send-pack and receive-pack, so that > what is agreed to be common between two parties will not shift in > the middle (in the same spirit that upload-pack grabs all the > relevant refs first, advertises them, negotiates what is common and > creates a pack, all using the same worldview of where the tips of > refs are throughout the process, even if some refs change in the > meantime). Upload-pack does that for protocol v0 ssh:// and git:// but not http(s)://, and does not do that for protocol v2, I believe. If we were to do that, I don't think it would work for the transports that have are stateless (e.g. HTTP). Also, this seems like it would involve a significant reworking of how the server serves (receive-pack would need to know to communicate just like upload-pack does temporarily before proceeding with its usual behavior, and the client would need to learn this new way - as opposed to the idea in this patch to do it separately and reuse the already existing fetch and push mechanisms). I think the greater complexity is not worth it for something that won't work in HTTP, but I'm open to other opinions.
