On Thu, Nov 05 2020, Jeff Hostetler wrote:
> However, the opportunity to introduce a prefix as I suggested earlier
> does offer the opportunity to introduce funky chars that would not
> have any protection, so you may want to c-quote the string when
> inserting it into the wire protocol.
>
> $ GIT_TRACE2_EVENT=1 GIT_TRACE2_PARENT_SID=hello git version
> {"event":"version","sid":"hello/20201030T154143.660608Z-H86606a97-
> P00001d30",...}
> ...
>
> (Allowing the user to insert a prefix like that has been useful for
> tracking control/experiment testing, so I wouldn't want to disable
> it.)
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.
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
