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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to