Junio C Hamano <gitster@xxxxxxxxx> writes: > What would be the end-user experience if you stopped at the first > error? You see an error, add an "fsck.<msg-id> = ignore" and rerun, > only to find another error and rinse and repeat? Wouldn't you > rather see all of them and add the "ignore" to cover them in one go? > >> I actually see a really good reason to *keep* the current behavior: >> one of the most prominent users of this code path is `git receive-pack >> --strict`. It is used heavily by GitHub to ensure at least a certain >> level of validity of pushed objects. Now, for this use case it is easy >> to see that you want to stop *as soon as an error was >> encountered*. And as GitHub sponsors my work on this patch series, my >> main aim is to support their use case. > > While I understand that use case, I do not think stopping after > showing three more errors in a single commit would make much > difference in the bigger picture. I actually changed my mind. The above talks about the value given to the end user by noticing as many errors in a single object, but I'd think fsck.<msg-id> is pretty much useless as a tool to keep using a repository with malformed object in its history. When you are told object d6602ec is bad (that's the v0.99 tag that does not have tagger field), you would never want to say "in this repository, any tag without tagger is allowed", because you would still want to catch and prevent future breakages of the same kind in new tags. And the way to do so is to say "I know the object d6602ec is bad, so do not report breakage you find to me" by using the skip-list. For that use case, showing _all_ errors (or warnings for that matter) does not add any value. So let's stop at the first error as your patch did. -- To unsubscribe from this list: send the line "unsubscribe git" in