Hi Junio, On Wed, 10 Dec 2014, Junio C Hamano wrote: > Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > > > We already have support in `git receive-pack` to deal with some legacy > > repositories which have non-fatal issues. > > > > Let's make `git fsck` itself useful with such repositories, too, by > > allowing users to ignore known issues, or at least demote those issues > > to mere warnings. > > > > Example: `git -c fsck.missing-email=ignore fsck` would hide problems with > > missing emails in author, committer and tagger lines. > > Hopefully I do not have to repeat myself, but please do not have > punctuations in the first and the last level of configuration variable > names, i.e. fsck.missingEmail, not mising-email. I vetted the complete patch series and think I caught them all. Or do you want the error messages to also use camelCased IDs, i.e. warning in tag $tag: missingTaggerEntry: invalid format ... instead of warning in tag $tag: missing-tagger-entry: invalid format ... ? It is easy to do, but looks slightly uglier to this developer's eyes... > Should these be tied to receive-pack ones in any way? E.g. if you > set fsck.missingEmail to ignore, you do not have to do the same for > receive and accept a push with the specific error turned off? > > Not a rhetorical question. I can see it argued both ways. The > justification to defend the position of not tying these two I would > have is so that I can be more strict to newer breakages (i.e. not > accepting a push that introduce a new breakage by not ignoring with > receive.fsck.*) while allowing breakages that are already present. > The justification for the opposite position is to make it more > convenient to write a consistent policy. Whichever way is chosen, > we would want to see the reason left in the log message so that > people do not have to wonder what the original motivation was when > they decide if it is a good idea to change this part of the code. Hmm. I really tried very hard to separate the fsck.* from the receive.* settings because the two code paths already behave differently: many warnings reported (and ignored) by fsck are fatal errors when pushing with receive.fsckObjects=true. My understanding was that these differences are deliberate, and my interpretation was that the fsck and the receive settings were considered to be fundamentally different, even if the same fsck machinery performs the validation. If you agree, I would rephrase this line of argument and add it to the commit message. Do you agree? Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html