Hi Junio,
On Mon, 22 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>
> > On Wed, 10 Dec 2014, Junio C Hamano wrote:
> >
> >> Johannes Schindelin <johannes.schindelin@xxxxxx> writes:
> >>
> >> > The 'invalid tag name' and 'missing tagger entry' warnings can now be
> >> > upgraded to errors by setting receive.fsck.invalid-tag-name and
> >> > receive.fsck.missing-tagger-entry to 'error'.
> >>
> >> Hmm, why can't all warnings promotable to errors, or are the above
> >> two mentioned only as examples?
> >
> > Those were the only ones that were always shown as warnings but never
> > treated as errors.
>
> Sorry but I don't quite understand this comment; I suspect the root
> cause might be that we have different mental models on these
> tweakable error severities.
>
> Because I come from the school "To these N kinds of events you can
> independently assign different (i.e. info, warn, error) outcomes",
> moving the FIRST_{INFO,WARNING,...} position in the array would only
> affect what happens by default, never hindering the user's ability
> to tweak (in other words, there is no linkage between "now you can
> tweak" and the order of events in the list, the latter of which only
> would affect what the default severity of each event is).
We agree on this mental model.
The only problem this patch tries to fix is that the warnings about a
missing tagger and about invalid tag names were never leading to an error.
They were purely printed, but then ignored. So what this patch does is to
add "if (err) return err;" handling for those two warnings.
As a consequence, the ordering of message IDs needs to be fixed because
the non-fatal warnings were ordered alphabetically before, but now the
non-fatal warnings are extracted so that we can give them the appropriate
FSCK_WARN by defauly – even in the git-receive-pack case.
In other words, the value assigned to those two warnings was completely
ignored before, which was the reason why it did not matter that we
assigned them to report FSCK_ERRORs in the git-receive-pack case before:
they were still only printed out and never stopped any tag from entering
the host's repository.
I could change the ordering in the patch that introduces the message IDs,
of course, but it would be even more puzzling if those two messages, of
all, were not ordered alphabetically with the others.
Ciao,
Dscho