Re: [PATCH v2 01/11] docs: new capability to advertise trace2 SIDs
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
Show 15 quoted lines
> 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"?
Show 7 quoted lines
> 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