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

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

Eric Sunshine <sunshine@sunshineco.com> writes:

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