Re: [PATCH v2 1/3] Move init_skiplist() outside of fsck

From: Jeff King <peff@peff.net>
Date: Jan 22, 2019, 18:28 UTC
Message-ID: <20190122182849.GD4399@sigill.intra.peff.net>
In-Reply-To: <87ef953tyn.fsf@evledraar.gmail.com>

On Tue, Jan 22, 2019 at 10:46:56AM +0100, Ævar Arnfjörð Bjarmason wrote:

Show 18 quoted lines

> > At which point, I think it might be simpler to just make git more
> > permissive with respect to those minor data errors (and in fact, we are
> > already pretty permissive for the most part in non-fsck operations).
> 
> Yeah it's probably better to make some of these "errors" softer
> warnings.
> 
> The X-Y issue I have is that I turned on transfer.fsckObjects, so then I
> can't clone repos with various minor historical issues in commit headers
> etc., so I maintain a big skip list. But what I was actually after was
> fsck checks like the .gitmodules security check.
>
> Of course I could chase them all down and turn them into
> warn/error/ignore individually, but it would be better if we e.g. had
> some way to say "serious things error, minor things warn", maybe with
> the option of only having the looser version on fetch but not recieve
> with the principle that we should be loose in what we accept from
> existing data but strict with new data #leftoverbits

Yeah, I think the current state here is rather unfortunate. The worst part is that many of the things _are_ marked as warnings, but we reject transfers even for warnings. So now we have "info" as well, which is really just silly.

I think the big blocker to simply loosening "warning" is that the current severities are pretty arbitrary. MISSING_NAME_BEFORE_EMAIL probably ought to be warning, but it's an warning. Whereas HAS_DOTGIT is a warning, but has pretty serious security implications.

So that does not save you from chasing them all down, but if you do, at least the work could benefit everybody. ;)

-Peff