Re: [PATCH 4/7] odb/source-loose: distinguish missing and corrupt objects

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

> @@ -91,11 +91,16 @@ static int read_object_info_from_path(struct odb_source_loose *loose,
>  		struct stat st;
>  
>  		if ((!oi || (!oi->disk_sizep && !oi->mtimep)) && (flags & OBJECT_INFO_QUICK)) {
> -			ret = quick_has_loose(loose, oid) ? 0 : -1;
> +			ret = quick_has_loose(loose, oid) ? 0 : 1;
>  			goto out;
>  		}
>  
>  		if (lstat(path, &st) < 0) {
> +			if (errno == ENOENT) {
> +				ret = 1;
> +				goto out;
> +			}
> +
>  			ret = -1;
>  			goto out;

Exactly the same comment about "turn it into an enum with meaningful
names once you add to an yes/no set a third choice" applies here.

> @@ -155,7 +163,7 @@ static int read_object_info_from_path(struct odb_source_loose *loose,
>  
>  		if (parse_loose_header(hdr, oi) < 0) {
>  			ret = error(_("unable to parse %s header"), oid_to_hex(oid));
> -			goto corrupt;
> +			goto out;
>  		}
>  
>  		if (*oi->typep < 0)
> @@ -165,7 +173,7 @@ static int read_object_info_from_path(struct odb_source_loose *loose,
>  			*oi->contentp = unpack_loose_rest(&stream, hdr, *oi->sizep, oid);
>  			if (!*oi->contentp) {
>  				ret = -1;
> -				goto corrupt;
> +				goto out;
>  			}
>  		}
>  
> @@ -173,21 +181,20 @@ static int read_object_info_from_path(struct odb_source_loose *loose,
>  	case ULHR_BAD:
>  		ret = error(_("unable to unpack %s header"),
>  			    oid_to_hex(oid));
> -		goto corrupt;
> +		goto out;
>  	case ULHR_TOO_LONG:
>  		ret = error(_("header for %s too long, exceeds %d bytes"),
>  			    oid_to_hex(oid), MAX_HEADER_LEN);
> -		goto corrupt;
> +		goto out;
>  	}
>  
>  	ret = 0;
>  
> -corrupt:
> -	if (ret && (flags & OBJECT_INFO_DIE_IF_CORRUPT))
> +out:
> +	if (ret < 0 && (flags & OBJECT_INFO_DIE_IF_CORRUPT))
>  		die(_("loose object %s (stored in %s) is corrupt"),
>  		    oid_to_hex(oid), path);

A missing object is not necessarily repository corruption, and the
code path to deal with it needs to jump here, so naming the label
"out:" is more appropriate.  OK.