Eric Sunshine <sunsh...@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.
