Re: [PATCH v2 01/11] docs: new capability to advertise trace2 SIDs
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 3, 2020, 21:33 UTC
- Message-ID
- <xmqq5z6mqg60.fsf@gitster.c.googlers.com>
- In-Reply-To
- <d04028c3c7574e3ca0f9c1b3d711192ca756158d.1604355792.git.steadmon@google.com>
Josh Steadmon <steadmon@google.com> writes:
Show 25 quoted lines
> +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.?