On Thu, Aug 24, 2017 at 6:19 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Brandon Williams <bmwill@xxxxxxxxxx> writes:
>
>> The best way to preserve functionality with old servers and clients would be to
>> communicate using the same end point but have the client send a bit of extra
>> information with its initial request. This extra information would need to be
>> sent in such a way that old servers ignore it and operate normally (using
>> protocol v1). The client would then need to be able to look at a server's
>> response to determine whether the server understands and is speaking v2 or has
>> ignored the clients request to use a newer protocol and is speaking v1.
>
> Good. I think the idle talk last round was for the server to tell
> the v1 client "we are still doing the slow ls-remote comes first
> protocol with this exchange, but just for future reference, you can
> use the v2 endpoint with me", which was way less desirable (even
> though it may be safer).
The idea that this RFC series tries to show case is safer IMO.
>> Patches 1-5 enable a client to unconditionally send this back-channel
>> information to a server. This is done by sending a version number after a
>> second NUL byte in git://, in the envvar GIT_PROTOCOL in file:// and ssh://,
>> and in an http header in http://, https://. Patches 6-7 teach a client and
>> upload-pack to send and recognize a request to use protocol v2.
>
> All sounds sensible.
>
> - for git://, if you say you found a hole in the protocol to stuff
> this information, I simply believe you ;-) Good job.
The hole is incredible funny and sad IMHO, so I would expect that
this series (specifically the review once it leaves RFC state) focusses
on how to allow future protocols with no such hacks. So AFAICT
the core idea of this series is that we can have an exchange
client through poked hole> "We can speak version 4,3, and 1 as fallback"
server > "Ok, 3 it is"
[ protocol v3 is executed, I don't know what it looks like. ]
Alternatively when the server is old:
client > "We can speak version 4,3, and 1 as fallback"
server > lists refs
client continues v1 as usual, because the version announcements
are so different from the first ref in the refs advertisement of v1,
such that the client knows for sure which version is talked. (despite
never getting an explicit "it is v1")
Or if the client is old:
client > (nothing)
server > lists refs, current v1 style.
> - http:// and https:// should be a no-brainer as the HTTP headers
> give ample room to send information from the initiator side.
>
> - For ssh://, I do not think it is sane to assume that we can
> convince server operators to allow passing any random environment
> variable. If the use of this specific variable turns out to be
> popular enough, however, and its benefit outweighs administrative
> burden, perhaps it is not impossible to convince them to allow
> AcceptEnv on this single variable.
Once the next generation protocol demonstrates it is far superior
than the current protocol admins will switch happily. (Some ideas:
(a) refstable instead packed-refs format, yielding better compression for
ref advertisement, (b) refs-in-want to cut down ref advertisement to
just the needs, (c) negotiation to draw from the remote reflog)
For now I would suggest we put a protocol v2 in place that is
the current protocol + a version number coming through the
poked hole at the beginning; the goal and review of this series
ought to focus on getting the version handshake right (and future
proof for an eventual v3 if needed in another 10 years)
Regarding the patches itself:
patches 1,2 seem ok, no further comment
patches 3-5 are the client stating that it can understand v2.
which means that patch 6 ("actually understand a v2, that
looks surprisingly similar to v1") should come before 3-5.
patch 7 can be either before or after 6, the server side
seems independent of the client side for the sake of
this patch series.
Thanks,
Stefan
>
> Thanks.
