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: > > > > 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. 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. Ciao, Dscho
