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
