Josh Steadmon <steadmon@xxxxxxxxxx> writes: > Document a new config option that allows users to determine whether or > not to advertise their trace2 session IDs to remote Git clients and > servers. I do not think placeing this in the trace2 hierarchy is a good idea. It is not like concept of "session" belongs to trace2; each operation we perform inherently is done on behalf of a session. The trace2 subsystem may have been the first to externalize the concept, but even after trace2 gets superseded, we would want to key our log records with some "session ID". After we introduce an improved mechanism that is successor to trace2, we still would want to exchange some session ID if the advertiseSID option the users define in their repository today (well, maybe in 3 months after this series lands in a released version and widely deployed), no? We are not exposing the session ID anywhere but the transports, so how about calling it transport.advertiseSID, perhaps? We also may want to call that just "session ID", not "trace2 session ID" in the description. Thanks. > Signed-off-by: Josh Steadmon <steadmon@xxxxxxxxxx> > --- > Documentation/config/trace2.txt | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/config/trace2.txt b/Documentation/config/trace2.txt > index 01d3afd8a8..3f2e3b4425 100644 > --- a/Documentation/config/trace2.txt > +++ b/Documentation/config/trace2.txt > @@ -69,3 +69,7 @@ trace2.maxFiles:: > write additional traces if we would exceed this many files. Instead, > write a sentinel file that will block further tracing to this > directory. Defaults to 0, which disables this check. > + > +trace2.advertiseSID:: > + Boolean. When true, client and server processes will advertise their > + trace2 session IDs to their remote counterpart. Defaults to false.
