Re: [PATCH v2 01/11] docs: new capability to advertise trace2 SIDs

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> AFAICT the way it's documented now is the "is the session-id[...]"
> paragraph in api-trace2.txt.
>
> I'd like to see us document the implementation a bit better and
> explicitly support the "hack" of setting GIT_TRACE2_PARENT_SID=hello.
>
> I.e. maybe I've missed something but we just say "session-id is
> prepended with the session-id of the parent" but don't mention that we
> separate them with slashes, so you can split on that to get the depth &
> individual ID's.
>
> My reading of the updated doc patch in v3 is that not allowing
> "non-printable or whitespace" allows you to e.g. have slashes in those
> custom session IDs, which would be quite inconvenient since it would
> break that property.

A few things I want to see stakeholders agree on:

 - In "a/b/c", what's the "session ID" of the leaf child process?
   "a/b/c"?  or "c"?  If the former (which is what I am guessing),
   do we have name to refer to "b" or "c" alone (if not, we should
   have one)?

 - Do we encourage/force other implementations of Git protocol to
   adopt a similar "slash-separated non-whitespace ASCII printable"
   structure?  I do not think such a structure is too limiting but
   others may feel differently.  Or is a "session ID" supposed to be
   an opaque token without any structure, and upon seeing "a/b/c"
   the recipient should not read anything into its slash, or any
   relation  with another session whose ID is "a/b/d"?

> And we should explicitly support the GIT_TRACE2_PARENT_SID=* setting
> from an external process, and make the SID definition loose enough to
> allow for SIDs that don't look like Git's in that chain. I.e. a useful
> property (and one I've seen in the wild) is to have some external
> programt that already has SIDs/UUID run IDs spawn git, setting
> GIT_TRACE2_PARENT_SID=<that program's SID> makes things convenient for
> the purposes of logging.n