Re: [PATCH v6 12/19] fsck: Disallow demoting grave fsck errors to warnings
From: Junio C Hamano <hidden>
Date: 2016-06-15 23:05:24
Johannes Schindelin [off-list ref] writes:
quoted hunk
Some kinds of errors are intrinsically unrecoverable (e.g. errors while uncompressing objects). It does not make sense to allow demoting them to mere warnings. Signed-off-by: Johannes Schindelin <redacted> --- fsck.c | 14 ++++++++++++-- t/t5504-fetch-receive-strict.sh | 11 +++++++++++ 2 files changed, 23 insertions(+), 2 deletions(-)diff --git a/fsck.c b/fsck.c index 21e3052..a4fbce3 100644 --- a/fsck.c +++ b/fsck.c@@ -9,7 +9,12 @@ #include "refs.h" #include "utf8.h" +#define FSCK_FATAL -1 + #define FOREACH_MSG_ID(FUNC) \ + /* fatal errors */ \ + FUNC(NUL_IN_HEADER, FATAL) \ + FUNC(UNTERMINATED_HEADER, FATAL) \ /* errors */ \ FUNC(BAD_DATE, ERROR) \ FUNC(BAD_DATE_OVERFLOW, ERROR) \@@ -39,11 +44,9 @@ FUNC(MISSING_TYPE, ERROR) \ FUNC(MISSING_TYPE_ENTRY, ERROR) \ FUNC(MULTIPLE_AUTHORS, ERROR) \ - FUNC(NUL_IN_HEADER, ERROR) \ FUNC(TAG_OBJECT_NOT_TAG, ERROR) \ FUNC(TREE_NOT_SORTED, ERROR) \ FUNC(UNKNOWN_TYPE, ERROR) \ - FUNC(UNTERMINATED_HEADER, ERROR) \
I think the end result very much makes a good sense, but why didn't this list enumerate the errors in the above "final" order from the beginning in 02/19?