Re: [PATCH v3 00/10] trace2: load trace2 settings from system config

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

"Jeff Hostetler via GitGitGadget" <gitgitgadget@gmail.com> writes:

> Here is version 3.
> [] It incorporates Ævar's suggestions WRT the format and uniqueness of the
> SID. [] It now reads both system and global config for trace2 settings and
> handles includes as Jonathan suggested.

Following the ISO more closely with Ts and Zs in the format looks
like a good idea (i.e. it gives a more familiar-looking result).  I
have no string opinions on the per-user config or inclusion, but I
think it probably is an essential ingredient to give an opt-out
escape hatch to make this appear less big-brotherly [*1*].

	Side note *1*: and hence less scary.  An otherwise useful
	mechanism can have an appearance that it can also be misused
	for bad purposes, and at that point, to those with fear, it
	does not matter how useful an application the mechanism has.

	I think "by default you are opting in due to your belonging
	to this organization in the first place (hence we give you
	/etc/gitconfig that lets us collect your usage patterns) but
	you could easily opt-out by overriding in $HOME/.gitconfig"
	strikes a good balance.

> I added a read_very_early_config() function that is similar to 
> read_early_config()but omits repo local, worktree, and -c command line
> settings. This felt like a little bit of a hack, but it made the intent
> clear.

I am not yet judging if the "very early config" itself is a good
thing to have (and if it is good, then it is not a "hack" ;-)), but
I very much agree that it is a very good change to have a helper
that makes the intent clear.

>      -+# Now test using system config by using a mocked up config file
>      -+# rather than inheriting "/etc/gitconfig".  Here we do not use
>      -+# GIT_TR2* environment variables.
>      -+
>       +unset GIT_TR2_BRIEF


This does not have to be sane_unset, as we are not aiming for making
our tests "set -e" clean.  But in tXXXX-*.sh scripts, it may not be
a bad idea to stick to sane_unset regardless, as people tend to cut
and paste without thinking enough.

>      @@ -512,19 +454,28 @@
>       + */
>       +/* clang-format off */
>
>      ++	[TR2_SYSENV_CFG_PARAM]     = { "GIT_TR2_CONFIG_PARAMS",
>      ++				       "trace2.configparams" },
>      ++
>      ++	[TR2_SYSENV_DST_DEBUG]     = { "GIT_TR2_DST_DEBUG",
>      ++				       "trace2.destinationdebug" },
>      ++
>      ++	[TR2_SYSENV_NORMAL]        = { "GIT_TR2",
>      ++				       "trace2.normaltarget" },
>      ++	[TR2_SYSENV_NORMAL_BRIEF]  = { "GIT_TR2_BRIEF",
>      ++				       "trace2.normalbrief" },
>      ++
>      ++	[TR2_SYSENV_EVENT]         = { "GIT_TR2_EVENT",
>      ++				       "trace2.eventtarget" },
>      ++	[TR2_SYSENV_EVENT_BRIEF]   = { "GIT_TR2_EVENT_BRIEF",
>      ++				       "trace2.eventbrief" },
>      ++	[TR2_SYSENV_EVENT_NESTING] = { "GIT_TR2_EVENT_NESTING",
>      ++				       "trace2.eventnesting" },
>      ++
>      ++	[TR2_SYSENV_PERF]          = { "GIT_TR2_PERF",
>      ++				       "trace2.perftarget" },
>      ++	[TR2_SYSENV_PERF_BRIEF]    = { "GIT_TR2_PERF_BRIEF",
>      ++				       "trace2.perfbrief" },


With use of designated initializers, the table got a lot cleaner to
read.  Is the above "format off" still needed (I am a bit curious
how clang-format wants these entries to look like)?

>      ++	if (pid > 999999)
>      ++		strbuf_addf(&tr2sid_buf, "W%06d", (int)(pid % 1000000));
>      ++	else
>      ++		strbuf_addf(&tr2sid_buf, "P%06d", (int)pid);

I do not think it matters too much, but this is kind-of curious.

How would the users of the log utilize the distinction between W and
P?  Do they discard the ones with W when they care about the exact
process that left the trace entries, or something?  If it's not a
plausibly useful use pattern (and I do not think it is), I wonder if
we want to go with only W (i.e. truncated to the lower N digits)
entries, if you are shooting for a fixed-width output from this
function.  If you want less chance of collisions, you obviously
could use hexadecimal to gain back a few more bits.

After all, if the application does care the PID, that could be in
the log data itself (i.e. an "start" event can say "my pid is blah").

Thanks.  I'll wait until learning what others think.