Re: [PATCH 1/2] parse-options: allow for configuring option abbreviation

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 1, 2019, 10:47 UTC
Message-ID: <xmqqtvfiuhn1.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CAPig+cR0Ldt3EpQ683ZFNFXggfsTrdeZ3R-V6pDBZNA1N3c+xg@mail.gmail.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

Show 11 quoted lines

> I don't get why having a configuration option is better for defending
> scripts against this problem than a simple environment variable. It
> seems easier for the script prologue to contain:
>
>     GIT_TEST_ABBREVIATED_OPTIONS=false
>     export GIT_TEST_ABBREVIATED_OPTIONS
>
> than for it to muck about with git-config or use "git -c
> core.abbreviatedOptions=false ..." everywhere. The commit message
> doesn't do a good enough job of justifying the configuration option
> over the environment variable.

Absolutely.

One thing that big brotherly types would find config attractive is to install centrally managed /etc/gitconfig so that they can tell the tracing machinery to log all git command invocations centrally; with environment only system, it is not easy to arrange.

But this one under discussion is probably a use case that is at the other end of the extreme from that.

Users (1) may use scripts written by third-parties, (2) may also develop their own scripts, and (3) even may run Git commands interactively.

It is a laudable goal to introduce a mechanism to "notice use of abbreviated options that happen to be unique right now but may not stay unique forever and warn against it". But (2) among the above three uses is the only use case that wants the protection, which makes the configuration a poor fit for the purpose.