On Sun, May 19 2019, SZEDER Gábor wrote: > For an environment variable that is supposed to be set by users, the > GIT_TR2* env vars are just too unclear, inconsistent, and ugly. > > Most of the established GIT_* environment variables don't use > abbreviations, and in case of the few that do (GIT_DIR, > GIT_COMMON_DIR, GIT_DIFF_OPTS) it's quite obvious what the > abbreviations (DIR and OPTS) stand for. But what does TR stand for? > Track, traditional, trailer, transaction, transfer, transformation, > transition, translation, transplant, transport, traversal, tree, > trigger, truncate, trust, or ...?! > > The trace2 facility, as the '2' suffix in its name suggests, is > supposed to eventually supercede Git's original trace facility. It's > reasonable to expect that the corresponding environment variables > follow suit, and after the original GIT_TRACE variables they are > called GIT_TRACE2; there is no such thing is 'GIT_TR'. > > All trace2-specific config variables are, very sensibly, in the > 'trace2' section, not in 'tr2'. > > OTOH, we don't gain anything at all by omitting the last three > characters of "trace" from the names of these environment variables. > > So let's rename all GIT_TR2* environment variables to GIT_TRACE2*, > before they make their way into a stable release. Good to see this land in 2.22.0. I wonder if we shouldn't take this further and rename trace2.* config to trace.*, and just re-use GIT_TRACE=1 instead of having GIT_TRACE2 as well, and have a GIT_TRACE_VERSION to switch between them. Then we could just switch in a future version. We've never promised what the trace format was going to look like, and the existing one isn't configurable (and we won't be making the v1 one...), so starting from the outset with "2" in config is unfortunate. We'd still have special snowflakes like e.g. GIT_TRACE_PACKET. OTOH we can just do this after the release if it's deemed a good idea, and just support trace2.* as aliases for trace.* for some amount of time, same for the env vars.
