Re: [WIP 08/15] connect: discover protocol version outside of get_remote_heads
From: Junio C Hamano <hidden>
Date: 2017-12-07 19:30:14
2 messages, 2 authors, 2017-12-08 · open the first message on its own page
From: Junio C Hamano <hidden>
Date: 2017-12-07 19:30:14
Brandon Williams [off-list ref] writes:
While we could wrap the preamble into a function it sort of defeats the purpose since you want to be able to call different functions based on the protocol version you're speaking. That way you can have hard separations between the code paths which operate on v0/v1 and v2.
As I envision that the need for different processing across protocol versions in real code would become far greater than it would fit in cases within a single switch() statement, I imagined that the reader structure would have a field that says which version of the protocol it is, so that the caller of the preamble thing can inspect it later to switch on it.
From: Brandon Williams <hidden>
Date: 2017-12-08 20:11:15
On 12/07, Junio C Hamano wrote:
Brandon Williams [off-list ref] writes:quoted
While we could wrap the preamble into a function it sort of defeats the purpose since you want to be able to call different functions based on the protocol version you're speaking. That way you can have hard separations between the code paths which operate on v0/v1 and v2.As I envision that the need for different processing across protocol versions in real code would become far greater than it would fit in cases within a single switch() statement, I imagined that the reader structure would have a field that says which version of the protocol it is, so that the caller of the preamble thing can inspect it later to switch on it.
Yes, patch 9 changes this so that the protocol version is stored in the transport structure. This way the fetch and push code can know what to do in v2. -- Brandon Williams