Re: [PATCH v6 10/19] fsck: Make fsck_tag() warn-friendly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin <johannes.schindelin@xxxxxx> writes:

> When fsck_tag() identifies a problem with the commit, it should try
> to make it possible to continue checking the commit object, in case the
> user wants to demote the detected errors to mere warnings.

I agree with that.  But if FSCK_MSG_BAD_OBJECT_SHA1 is an ignorable
error, why should we still have a conditional "goto done" here?

Shouldn't we be parsing the object the same way regardless?

>
> Just like fsck_commit(), there are certain problems that could hide other
> issues with the same tag object. For example, if the 'type' line is not
> encountered in the correct position, the 'tag' line – if there is any –
> would not be handled at all.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx>
> ---
>  fsck.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fsck.c b/fsck.c
> index 0cfa4d0..21e3052 100644
> --- a/fsck.c
> +++ b/fsck.c
> @@ -640,7 +640,8 @@ static int fsck_tag_buffer(struct tag *tag, const char *data,
>  	}
>  	if (get_sha1_hex(buffer, sha1) || buffer[40] != '\n') {
>  		ret = report(options, &tag->object, FSCK_MSG_BAD_OBJECT_SHA1, "invalid 'object' line format - bad sha1");
> -		goto done;
> +		if (ret)
> +			goto done;
>  	}
>  	buffer += 41;
--
To unsubscribe from this list: send the line "unsubscribe git" in



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]