From: Patrick Steinhardt <ps@pks.im>
Date: Fri, 16 Jan 2026 07:03:31 GMT
Subject: Re: [PATCH 04/14] object-file: introduce function to iterate through objects
Message-ID: <aWniwzCL5S6FD3N9@pks.im>
In-Reply-To: <aWlSYGIe5izqWwte@denethor>

On Thu, Jan 15, 2026 at 02:54:23PM -0600, Justin Tobler wrote:
> On 26/01/15 12:04PM, Patrick Steinhardt wrote:
> > We have multiple divergent interfaces to iterate through objects of a
> > specific backend:
> > 
> >   - `for_each_loose_object()` yields all loose objects.
> > 
> >   - `for_each_packed_object()` (somewhat obviously) yields all packed
> >     objects.
> > 
> > These functions have different function signatures, which makes it hard
> > to create a common abstraction layer that covers both of these.
> 
> I assume that the intention is to eventually have a generic
> for_each_object() function that can iterate across objects regardless of
> the source. Is the end goal to have each source define the appropriate
> for_each_object callback?

Yup.

> > Introduce a new function `odb_source_loose_for_each_object()` to plug
> > this gap. This function doesn't take any data specific to loose objects,
> > but instead it accepts a `struct object_info` that will be populated the
> > exact same as if `odb_source_loose_read_object()` was called.
> > 
> > The benefit of this new interface is that we can continue to pass
> > backend-specific data, as `struct object_info` contains a union for
> > these exact use cases. This will allow us to unify how we iterate
> > through objects across both loose and packed objects in a subsequent
> > commit.
> 
> Naive question: in a future where we have additional ODB backends, does
> this mean that `struct object_info` would also need to be updated to
> include them?

Yes. We'd introduce a new `OI_*` type to signifiy the specific backend
via the `whence` fieldand will (optionally) have a new member in the
union of backend-specific data.

Patrick