Re: [RFC PATCH] push: perform negotiation before sending packfile

From: Jonathan Tan <jonathantanmy@google.com>
Date: Feb 19, 2021, 00:42 UTC
Message-ID: <20210219004242.1179999-1-jonathantanmy@google.com>
In-Reply-To: <xmqqy2fldsy4.fsf@gitster.g>

Show 8 quoted lines

> 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.