Re: [PATCH 0/3] Strengthen fsck checks for submodule URLs

[Junio C Hamano <gitster@pobox.com>]

Neil Mayhew <neil@mayhew.name> 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.