Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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
