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

> Eric Sunshine <sunshine@sunshineco.com> writes:
>
>>> @@ -1554,23 +1554,42 @@ filter.<driver>.smudge::
>>> +Depending on the circumstances it might be better to use
>>> +`fsck.skipList` instead to explicitly whitelist those objects that
>>> +have issues, otherwise new occurrences of the same issue will be
>
> I had to read the "instead to ..." part three times before
> convincing myself that this is a good description, and I agree with
> the assessment.  Perhaps we would want to make the recommendation a
> bit stronger, even.
>
>         In general, it is better to enumerate existing objects with
>         problems with skipList, instead of listing the kind of
>         breakages these problematic objects share to be ignored, as
>         doing the latter will allow new instances of the same
>         breakages go unnoticed.
>
> If the project has some tool constraints and have to accept new
> "broken" objects on ongoing basis, then fsck.<msg-id> facility may
> make sense, but that is probably a very narrow special use case.

>>> +hidden going forward, although that's unlikely to happen in practice
>>> +unless someone is being deliberately malicious.
>>
>> Is it worth mentioning buggy tools and/or other buggy Git
>> implementations as sources?
>
> Or old Git implementations we ourselves shipped.  I do not think it
> is worth mentioning it, but I do agree that "unless somebody is
> being deliberatly malicious" is misleading, if that is what you are
> getting at.  One use of fsck is about noticing that you are under
> attack, so "unless someone is being malicious" there in the sentence
> does not make sense.  When somebody is attacking you, you do not
> want to use fsck.<msg-id> to ignore it.
>
> But that becomes a moot point, if we were to follow the line of
> rewrite I suggested above.