Hi Michael,
On 2015-02-02 13:43, Michael Haggerty wrote:
> On 02/02/2015 12:41 PM, Johannes Schindelin wrote:
>> 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).
>
> Why "level"?
"Severity level", or "error level". Maybe ".severity." would be better?
>> 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.
>
> I again encourage you to consider skipping the implementation of
> command-line options entirely. It's not like users are going to want to
> use different options for different invocations. Let them use
>
> git -c fsck.level.missingAuthor=ignore fsck
>
> if they really want to play around, then
>
> git config fsck.level.missingAuthor ignore
>
> to make it permanent. After that they will never have to worry about
> that option again.
Unfortunately, I have to pass the `receive.fsck.*` settings from `git-receive-pack` to `git-unpack-objects` or `git-index-pack` via the command-line, because it is `git-receive-pack` that consumes the config setting, but it is one of `git-unpack-objects` and `git-index-pack` that has to act on it...
> And Postel needn't be offended :-)
;-)
Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html