Re: [PATCH v2 2/5] config doc: unify the description of fsck.* and receive.fsck.*

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 1, 2018, 00:11 UTC
Message-ID: <xmqq4lincqna.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <87fu289tph.fsf@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 8 quoted lines

> It's our documentation that should be clearly stating those reasons. If
> we're not saying anything about these being historical bugs, then e.g. I
> (not knowing the implementation) wouldn't have turned this on globally
> on my site knowing that because I have none of these now I'm *very*
> unlikely to have them in the future.
>
> That's different from something that just happens rarely, because a rare
> non-historical event can be expected to happen in the future.

Interesting. If I did not know Git at all, I would decide completely opposite---because I have none of these now, I'm very unlikely to have them in the future, so I would leave fsck.<msg-id> alone to the generally recommended state (i.e. not customizing without understanding what I am doing). That way, (1) if that unlikely thing happens, I would notice and have a chance to deal with it, and (2) otherwise, I wouldn't have to worry about that unlikely event at all.

And that decision would not change even if I _knew_ these knobs' categories were invented to align with bugs and anomalies in older implementations of Git.

Show 12 quoted lines

>
>> Between "fsck.<msg-id> makes sense only when you use these rare and
>> you-probably-never-heard-of tools ongoing basis" and "when you
>> already have (slightly)broken objects, naming each of them in
>> skiplist, rather than covering the class, is better because you want
>> *new* instances of the same breakage", I'd imagine the latter would be
>> more helpful.
>>
>> In any case, let's see if there are more input to this topic and
>> then wrap it up in v3 ;-)
>>
>> Thanks.