Neil Mayhew <neil@xxxxxxxxxxx> writes: > ... immediately corrected by another commit. However, the bad commit is > still in the history. It happened 6 years ago, so there's no > possibility of us changing the history. I think fsck.skipList was meant to cover such a case. The idea is that the blob object name of the bad .gitmodules file can be placed on the list, and the rest of the "bad commit" and the whole history can still be checked for consistency, without triggering the warning (or error) resulting from the offending .gitmodules file. > Is there any possibility of "loosening the fsck.gitmodulesUrl > severity", as Jeff suggested? Isn't the suggestion not about butchering the rest of the world but by locally configuring fsck.gitmodulesUrl down from error to warning? I personally think excluding a single known-offending blob without doing such loosening is a much better idea in that it prevents *new* offending instances from getting into the repository, while allowing an existing benign and honest mistake to stay in your history. Loosening the severity of a class of check means you will accept *new* offending instances, which may very well be malicious, unlike the existing benign one you know about.
