On 2020.11.03 13:33, Junio C Hamano wrote: > Josh Steadmon <steadmon@xxxxxxxxxx> writes: > > > +trace2-sid=<session-id> > > +----------------------- > > + > > +If trace2 tracing is enabled on the server, it may advertise its session ID via > > +this capability. The client may choose to log the server's session ID in its > > +trace logs, and advertise its own session ID back to the server for it to log > > +as well. This allows for easier debugging of remote sessions when both client > > +and server logs are available. > > diff --git a/Documentation/technical/protocol-v2.txt b/Documentation/technical/protocol-v2.txt > > index e597b74da3..a5b9ef04f6 100644 > > --- a/Documentation/technical/protocol-v2.txt > > +++ b/Documentation/technical/protocol-v2.txt > > @@ -492,3 +492,12 @@ form `object-format=X`) to notify the client that the server is able to deal > > with objects using hash algorithm X. If not specified, the server is assumed to > > only handle SHA-1. If the client would like to use a hash algorithm other than > > SHA-1, it should specify its object-format string. > > + > > +trace2-sid=<session-id> > > +~~~~~~~~~~~~~~~~~~~~~~~ > > + > > +If trace2 tracing is enabled on the server, it may advertise its session ID via > > +this capability. The client may choose to log the server's session ID in its > > +trace logs, and advertise its own session ID back to the server for it to log > > +as well. This allows for easier debugging of remote sessions when both client > > +and server logs are available. > > Have we documented what a session-id should look like anywhere in > the documentation? This document is to help third-party to write > implementations of the protocol, but the above description leaves > things "implementation defined" a bit too much, I am afraid. > > For example, as this must fit on a single pkt-line as an advertised > capability, there would be some length limit. Are there other > inherent limitations due to our protocol? Are there some artificial > limitations that we may want to impose to make it easier to harden > implementations against common mistakes? For example are bytes in > <session-id> allowed to contain LF, CR, NUL, etc.? Documented in V3. For argument's sake, I'm going to say that the tokens should be limited to printable, non-whitespace characters, and should fit on a single pkt-line.
