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