Re: [PATCH v2 0/5] odb: handle `OBJECT_INFO_DIE_IF_CORRUPT` generically

Karthik Nayak <[email protected]> Thu, 20 Aug 2026 10:14:59 -0400

Newsgroups	org.kernel.vger.git
Message-ID	<CAOLa=ZTVxdVAJynKjb0LjmZ-+b5nQmyD0Bm-aT81rOOdJ0a5yg@mail.gmail.com>

Patrick Steinhardt <[email protected]> writes:

> Hi,
>
> when looking up an object with `OBJECT_INFO_DIE_IF_CORRUPT` fails we
> want to die in case the object exists but is corrupted. This flag is
> handled in two different spots right now:
>
>   - `do_oid_object_info_extended()` calls `has_packed_and_bad()` to
>     check whether the object is known to be corrupt in any packfile.
>     This function reaches into the internals of the packed source and
>     thus breaks the abstraction provided by our object sources.
>
>   - The loose source handles the flag itself and dies directly in
>     `read_object_info_from_path()`, which means that we die even in
>     cases where another source may still have a good copy of the
>     object.
>
> Besides being inconsistent, it also ties us to the specific backend used
> by the database sources because `has_packed_and_bad()` assumes that they
> use the "files" backend. Any other backend will instead cause us to die
> when calling `odb_source_files_downcast()`, even if the object was
> simply nonexistent.
>
> This series fixes these issues and makes the check backend-agnostic by
> extending semantics of `odb_source_read_object_info()`: on the one hand
> it now distinguishes whether an object is missing or corrput, and on the
> other hand it starts to return an error message to the caller.
>
> Changes in v2:
>   - Adapt the series to use an `enum odb_read_status` with negative
>     error codes exclusively, as suggested by Junio. This results in a
>     rather big restructure of the series.
>   - Link to v1: https://patch.msgid.link/20260818-pks-odb-generic-corrupt-objects-v1-0-ec234567510f@pks.im
>

Small questions from me, looks good otherwise! :)

[snip]

signature.asc (application/pgp-signature, 690 B)