Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

Jonathan Nieder [off-list ref] writes:

If we want to make the advertised protocol versions on the server side
configurable, I think it should be independent from the configuration
for protocol versions to use on the client side.  Rationale:

 - As a client-side user, I may want to (after reporting the bug, of
   course!) blacklist certain protocol versions to work around server
   bugs.  But this should not affect my behavior as a server --- in
   my role as a server, these server-side bugs have no effect on me.

 - As a server operator, I may want to (after reporting the bug, of
   course!) blacklist certain protocol versions to work around client
   bugs.  But this should not affect my behavior as a client --- in my
   role as a client, these client-side bugs have no effect on me.

Good point.  

Making the client-side case configurable seems important since Git is
widely used in environments where it may not be easy to control the
deployed version (so having configuration as an escape hatch is
important).

Making the server-side case configurable seems less important since
Git server operators usually have tight control over the deployed Git
version and can apply a targetted fix or workaround.

The above also suggests that the configuration variable that lets
you specify the protocol version should hint in its name which
direction of the protocol it controls.  Even if we decide that we'd
add only the variable for the initiator side for now, if it is
possible that we later may want to add another for the acceptor
side, we need to do it right from day one.

Perhaps protocol.connectVersion(s) vs protocol.acceptVersion(s) or
something like that?