Web lists-archives.com

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

Hi Junio,

On Mon, 1 Apr 2019, Junio C Hamano wrote:

> Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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:
> >
> >
> > 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.

I think that in this instance, we should use the fact that we know Ævar
well, and refrain from characterizing him as a Big Brotherly type.

From my reading, it looks like Ævar just wants to avoid being woken up for
a Live Site Incident that is caused by a violation of Postel's Law: be
accepting in your input, but stringent in your output. And in this case,
the scripts by their colleagues is the output that should be more
stringent, and enforcing the stringency via a system-wide config variable
is as legit as our instistence that `user.name` and `user.email` must be
provided if you want to create a commit.

And I would not have the faintest problem with adding that patch to
introduce the `core.*` setting to that end (which would be the right
section, too, even if there are already so many `core.*` settings).

Having said that, I get the strong impression that there is a rather
violent pushback against this (which I don't understand). Combined with
the fact that it would protect only against a tiny fraction of "git
upgrade problems", I'm getting more into the "well, then let's just not
bother" camp.