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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 12, 2019, 02:29 UTC
Message-ID: <xmqqv9zkymzd.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <pull.169.v3.git.gitgitgadget@gmail.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.

Show 5 quoted lines

>      -+# 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.

Show 26 quoted lines

>      @@ -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.