Re: Add warning when v0 protocol is used/downgraded

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Devste Devste wrote:

> - When "git config protocol.version 2" is used, there is no
> warning/message when the remote returns a response in v0 format. This
> leads to any issues related to slow(er) git caused by old protocol use
> being unnoticed, leading to wasted time debugging.

Specifying protocol version is meant to be backward compatible, and
there are cases where the old protocol still needs to be used - for
example, if an SSH server doesn't support transmitting the
GIT_PROTOCOL environment variable, then having the fallback to v0 is
still useful there.

So I'd be concerned that printing the protocol version in the default
case would be overly disruptive for such cases.  This would be even
more so for protocol v2 for push, which doesn't exist yet - once it
exists, it wouldn't be great if all pushes using existing servers
produced an extra piece of noisy output. :)

That said, I'm sympathetic to the debugging use case you've described
here.  Do tools like GIT_TRACE_PACKET, GIT_TRACE2_EVENT, and "git
bugreport" produce the right information in these scenarios?  Would
"git fetch -v" (i.e., when the user has explicitly asked git to be
more verbose) be a good place to provide some additional diagnostic
output?

> If
> protocol.version is not explicitly set or v2
> and both the local and server git version are >=2.26
> and the reply is not in v2 protocol format

Interesting!  We haven't previously used the "agent" field (server
version) for anything other than logging it verbatim; I'd worry a bit
about getting into the same kind of mess as User-Agent parsing on the
web if we go that direction.  But I would expect the main obstacles to
updating protocol version support to be in (a) reimplementations of
git protocol rather than the standard git reference implementation and
(b) plumbing such as httpd and sshd around git, rather than git
itself.

Thanks and hope that helps,
Jonathan