Re: [PATCH v4 00/19] Introduce an internal API to interact with the fsck machinery

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 2, 2015, 11:41 UTC
Message-ID: <060e1e6a5530dfb311074b0aa854b281@www.dscho.org>
In-Reply-To: <cover.1422737997.git.johannes.schindelin@gmx.de>

Hi all (in particular Junio),

On 2015-01-31 22:04, Johannes Schindelin wrote:

> [...] switch to fsck.severity to address Michael's
> concerns that letting fsck.(error|warn|ignore)'s comma-separated lists
> possibly overriding each other partially;

Having participated in the CodingStyle thread, I came to the conclusion that the fsck.severity solution favors syntax over intuitiveness.

Therefore, I would like to support the case for `fsck.level.missingAuthor` (note that there is an extra ".level." in contrast to earlier suggestions).

The benefits:

- it is very, very easy to understand

- cumulative settings are intuitively cumulative, i.e. setting `fsck.level.missingAuthor` will leave `fsck.level.invalidEmail` completely unaffected

- it is very easy to enquire and set the levels via existing `git config` calls

Now, there is one downside, but *only* if we ignore Postel's law.

Postel's law ("be lenient in what you accept as input, but strict in your output") would dictate that our message ID parser accept both "missing-author" and "missingAuthor" if we follow the inconsistent practice of using lowercase-dashed keys on the command-line but CamelCased ones in the config.

However, earlier Junio made very clear that the parser is required to fail to parse "missing-author" in the config, and to fail to parse "missingAuthor" on the command-line.

Therefore, the design I recommend above will require two, minimally different parsers for essentially the same thing.

IMHO this is a downside that is by far outweighed by the ease of use of the new feature, therefore I am willing to bear the burden of implementation.

Do you agree?

Ciao, Dscho