On 6 October 2017 at 14:09, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Martin Ågren <martin.agren@xxxxxxxxx> writes: > >> Maybe I'm missing something Git-specific, but isn't the only thing that >> needs to be done now, to document/specify that 1) the client should send >> its list ordered by preference, 2) how preference is signalled, and 3) >> that the server gets to choose? > > I think Simon's reminder of Stefan's was about specifying something > different from (1) above---it was just a list of good ones (as > opposed to ones to be avoided). I was suggesting to tweak that to > match what you wrote above. I replied to your mail, but also to the general notion of "we need a carefully designed configuration and fall-back strategy before we can include this series" which I sensed (and which I hope I didn't just misrepresent). I didn't make it very clear exactly what I was replying to, sorry about that. Note that my 1-3 above are not about "configuration", which I interpret as "how does the user tell Git how to select a protocol version?", but about the protocol, i.e., "how do the client and server agree on which version to use?". >> Why would a server operator with only v0 and v1 at their disposal want >> to choose v0 instead of v1, considering that -- as far as I understand >> -- they are in fact the same? > > Because we may later discover some reason we not yet know that makes > v$n+1 unsuitable after we introduce it, and we need to avoid it by > preferring v$n instead? For n in general, I agree completely. For n=0, and in particular for a Git which only knows v0 and v1, I'm not so sure. If v1 has a problem which v0 doesn't, then to the best of my understanding, that problem would be in this series, i.e., in the version-negotiation. And to minimize risk in that area, we'd want to make this series more complex? That might be the correct thing to do -- certainly, if we botch this series totally, then we might be in big trouble going forward --, but it's not at all obvious to me. Nor is it obvious to me that such an escape-hatch needs to be a multi-choice, prioritized configuration. If a fall-back mechanism to v0 is wanted on the first Git server with v1/v0, the simplest approach might be to make the server respect protocol.version (possibly with a default of 1!?). I might be naive in thinking that protocol.version could be removed or redefined at our discretion just because it's marked as "experimental". Martin
