Re: [PATCH 3/3] CodingGuidelines: describe naming rules for configuration variables

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 2, 2015, 11:31 UTC
Message-ID: <687227472e6697fadfa9c3237c9c7de0@www.dscho.org>
In-Reply-To: <xmqqwq418dmp.fsf@gitster.dls.corp.google.com>

Hi,

On 2015-02-01 23:34, Junio C Hamano wrote:

Show 9 quoted lines

> Jeff King <peff@peff.net> writes:
> 
>>   1. I'm a user who has set my preferred core.whitespace in my
>>      ~/.gitconfig. A particular project I am working on uses an
>>      alternate tabwidth. How do I set that in the repo config without
>>      repeating my defaults?
> 
> Isn't it cumulative?  At least it should be (but I wouldn't be too
> surprised if the recent config reader caching broke it).

Please note that it is really, really difficult for a regular Git user to figure out which whitespace settings are in effect using just `git config` whether it is cumulative or not.

Also, please note it makes it hard on users that there are a bunch of config settings which *override* previous settings, and others that are *cumulative*.

The latter we cannot change, and the former we cannot change for the whitespace settings. However, when introducing new settings (such as the fsck severity levels), we should go out of our way to keep things as simple as possible. For example, if a *simple* `git config` can answer the question "Is feature XYZ turned on", I would consider the design superior to a design that requires additional code just to figure out whether feature XYZ is turned on, let alone to turn it on without affecting other settings.

In other words, I would like to caution against recommending the whitespace setting as an example to follow: anybody who is unfamiliar with the whitespace setting will find the cumulative last-setting-wins (per item inside the whitespace-separated list, not per config setting) strategy confusing.

On the other hand, if you offer `whitespace.tabWidth` and `whitespace.indentWithNoTab` separately, everything is really crystal clear to new users without having much explaining to do, let alone having to introduce new tooling.

Ciao, Dscho

P.S.: Of course I know that it is too late for `whitespace`, but it offers itself as a good subject to demonstrate the merits of the different suggestions.