On Tue, Jan 22, 2019 at 10:46:56AM +0100, Ævar Arnfjörð Bjarmason wrote: > > 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
