Re: [PATCH 04/18] Offer a function to demote fsck errors to warnings
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 10, 2014, 18:00 UTC
- Message-ID
- <xmqqoarbidv7.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <2a0c4cd4c5d3aaceff8a6ffa49d2f3597d26086d.1418055173.git.johannes.schindelin@gmx.de>
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
Show 39 quoted lines
> There are legacy repositories out there whose older commits and tags
> have issues that prevent pushing them when 'receive.fsckObjects' is set.
> One real-life example is a commit object that has been hand-crafted to
> list two authors.
>
> Often, it is not possible to fix those issues without disrupting the
> work with said repositories, yet it is still desirable to perform checks
> by setting `receive.fsckObjects = true`. This commit is the first step
> to allow demoting specific fsck issues to mere warnings.
>
> The function added by this commit parses a list of settings in the form:
>
> missing-email=warn,bad-name=warn,...
>
> Unfortunately, the FSCK_WARN/FSCK_ERROR flag is only really heeded by
> git fsck so far, but other call paths (e.g. git index-pack --strict)
> error out *always* no matter what type was specified. Therefore, we
> need to take extra care to default to all FSCK_ERROR in those cases.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> fsck.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> fsck.h | 7 +++++--
> 2 files changed, 63 insertions(+), 2 deletions(-)
>
> diff --git a/fsck.c b/fsck.c
> index 05b146c..9e6d70f 100644
> --- a/fsck.c
> +++ b/fsck.c
> @@ -97,9 +97,63 @@ static int parse_msg_id(const char *text, int len)
>
> int fsck_msg_type(enum fsck_msg_id msg_id, struct fsck_options *options)
> {
> + if (options->strict_mode && msg_id >= 0 && msg_id < FSCK_MSG_MAX)
> + return options->strict_mode[msg_id];
> + if (options->strict)
> + return FSCK_ERROR;
> return msg_id < FIRST_WARNING ? FSCK_ERROR : FSCK_WARN;
> }Hmm, if you are later going to allow demoting (hopefully also promoting) error to warn, etc., would the comparison between msg_id and FIRST_WARNING make much sense?
In other words, at some point wouldn't we be better off with something like this
struct {
enum id;
const char *id_string;
enum error_level { FSCK_PASS, FSCK_WARN, FSCK_ERROR };
} possible_fsck_errors[];