From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/7] odb/source: discern missing and corrupt objects
Date: Tue, 18 Aug 2026 11:00:40 -0700 [thread overview]
Message-ID: <xmqqh5krz4tz.fsf@gitster.g> (raw)
In-Reply-To: <20260818-pks-odb-generic-corrupt-objects-v1-1-ec234567510f@pks.im> (Patrick Steinhardt's message of "Tue, 18 Aug 2026 16:19:28 +0200")
Patrick Steinhardt <ps@pks.im> writes:
> The `read_object_info()` callback of `struct odb_source` is documented
> to return a negative error code in case reading the object has failed,
> and zero otherwise. This is overly broad though, as there are two very
> different kinds of failures:
>
> - The object may not exist in the source at all.
>
> - The object exists, but reading it has failed, for example because
> its on-disk state is corrupt.
>
> This distinction matters to callers: when an object is corrupt in one
> source we may still find a good copy of it in another source, so we may
> still be able to proceed with a given operation.
>
> The "packed" source already distinguishes these cases by returning a
> positive value for missing objects and a negative value in case reading
> the object has failed. But all the other sources conflate them into a
> single negative return value.
In other words, "packed" did not honor the documented contract with
the callers and nobody noticed? It gives us a usable escape hatch ;-)
Do we need to support many other "it is an error but we treat as non
error in some context" values, like the "does not exist"? If so, it
does make sense to say 0 is absolute success, positive values are
such half-errors, and negative values are absolute failures. If
not, it would have been much nicer if "you asked me about this
information but there is no such object" were still signalled as an
error (i.e., negative return value) that is distinct from other
kinds of errors like I/O error (which also should be signalled by a
negative return value), instead of a positive value whose meanings
were not defined, though.
> Adapt the documentation to explicitly require the semantics of the
> "packed" backend, where we return a positive value for missing objects
> and a negative value for corrupt ones. Subsequent commits will adapt all
> the other implementations to respect those new semantics.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> odb/source.h | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/odb/source.h b/odb/source.h
> index d69f8e2d1c..4ae6cc160e 100644
> --- a/odb/source.h
> +++ b/odb/source.h
> @@ -110,8 +110,17 @@ struct odb_source {
> * second read in case they know that the first read would have
> * already surfaced the object without reloading any on-disk state.
> *
> - * The callback is expected to return a negative error code in case
> - * reading the object has failed, 0 otherwise.
> + * The callback is expected to return one of the following values:
> + *
> + * - Zero in case the object has been found and its object info has
> + * been read successfully.
> + *
> + * - A positive value in case the object does not exist in this
> + * source.
> + *
> + * - A negative value in case the object exists in this source, but
> + * reading its object info has failed, for example because its
> + * on-disk state is corrupt.
> */
> int (*read_object_info)(struct odb_source *source,
> const struct object_id *oid,
> @@ -340,7 +349,9 @@ static inline void odb_source_prepare(struct odb_source *source,
>
> /*
> * Read an object from the object database source identified by its object ID.
> - * Returns 0 on success, a negative error code otherwise.
> + * Returns 0 on success, a positive value in case the object is missing in the
> + * source and a negative value in case the object exists, but reading it has
> + * failed.
> */
> static inline int odb_source_read_object_info(struct odb_source *source,
> const struct object_id *oid,
next prev parent reply other threads:[~2026-08-18 18:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 14:19 [PATCH 0/7] odb: handle `OBJECT_INFO_DIE_IF_CORRUPT` generically Patrick Steinhardt
2026-08-18 14:19 ` [PATCH 1/7] odb/source: discern missing and corrupt objects Patrick Steinhardt
2026-08-18 18:00 ` Junio C Hamano [this message]
2026-08-18 14:19 ` [PATCH 2/7] odb/source-inmemory: signal missing objects via positive return Patrick Steinhardt
2026-08-18 18:05 ` Junio C Hamano
2026-08-18 14:19 ` [PATCH 3/7] odb/source-packed: flag known-bad objects as corrupt and not missing Patrick Steinhardt
2026-08-18 18:17 ` Junio C Hamano
2026-08-18 14:19 ` [PATCH 4/7] odb/source-loose: distinguish missing and corrupt objects Patrick Steinhardt
2026-08-18 18:23 ` Junio C Hamano
2026-08-18 14:19 ` [PATCH 5/7] odb/source-files: signal mark objects via positive return Patrick Steinhardt
2026-08-18 18:58 ` Junio C Hamano
2026-08-18 14:19 ` [PATCH 6/7] odb/source: allow `read_object_info()` to bubble up error messages Patrick Steinhardt
2026-08-18 14:19 ` [PATCH 7/7] odb: handle `OBJECT_INFO_DIE_IF_CORRUPT` generically Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqh5krz4tz.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.