Subject: Re: [PATCH 16/18] fsck: support demoting errors to warnings

From: Junio C Hamano <[email-masked]>
Date: Mon, 22 Dec 2014 14:34:39 -0800

Johannes Schindelin <[email-masked]> writes:

> 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...

Do you really need to know what I think?  Can I say "The latter is
probably slightly better, but both look ugly to me"?

If we want a human readable message

    "warning: tag object lacks tagger field '$tag'"

would be my preference.

But I personally think it may not be necessary to give a pretty
message that later can go through l10n here.  If we take that
position, it is just a machine-readble error token, so I'd say
whichever way you find more readable is OK.

>> 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:...
>
> If you agree, I would rephrase this line of argument and add it to the
> commit message. Do you agree?

Yeah, that reasoning sounds sensible.

Thanks.