From: Johannes Schindelin <johannes.schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>,
Michael Haggerty <mhagger@alum.mit.edu>,
git@vger.kernel.org
Subject: Re: [PATCH 3/3] CodingGuidelines: describe naming rules for configuration variables
Date: Mon, 02 Feb 2015 12:31:26 +0100 [thread overview]
Message-ID: <687227472e6697fadfa9c3237c9c7de0@www.dscho.org> (raw)
In-Reply-To: <xmqqwq418dmp.fsf@gitster.dls.corp.google.com>
Hi,
On 2015-02-01 23:34, Junio C Hamano wrote:
> 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.
next prev parent reply other threads:[~2015-02-02 11:31 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-26 16:55 [PATCH] Documentation/git-add.txt: add `add.ginore-errors` configuration variable Alexander Kuleshov
2015-01-26 21:58 ` Eric Sunshine
2015-01-27 20:17 ` Junio C Hamano
2015-01-28 22:33 ` [PATCH 0/3] Documenting naming rules for configuration variables Junio C Hamano
2015-01-28 22:33 ` [PATCH 1/3] config.txt: clarify that add.ignore-errors is deprecated Junio C Hamano
2015-01-28 22:33 ` [PATCH 2/3] config.txt: mark deprecated variables more prominently Junio C Hamano
2015-01-28 22:33 ` [PATCH 3/3] CodingGuidelines: describe naming rules for configuration variables Junio C Hamano
2015-02-01 5:12 ` Michael Haggerty
2015-02-01 16:44 ` Jeff King
2015-02-01 20:18 ` Junio C Hamano
2015-02-01 21:57 ` Jeff King
2015-02-01 22:34 ` Junio C Hamano
2015-02-02 11:31 ` Johannes Schindelin [this message]
2015-02-02 18:39 ` Junio C Hamano
2015-02-02 6:47 ` Michael Haggerty
2015-02-02 18:54 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=687227472e6697fadfa9c3237c9c7de0@www.dscho.org \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mhagger@alum.mit.edu \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).