Re: [PATCH 07/14] odb: introduce `odb_for_each_object()`

[Patrick Steinhardt <ps@pks.im>]

On Fri, Jan 16, 2026 at 11:46:12AM -0600, Justin Tobler wrote:
> On 26/01/15 12:04PM, Patrick Steinhardt wrote:
> > diff --git a/odb.h b/odb.h
> > index f97f249580..8f6d95aee5 100644
> > --- a/odb.h
> > +++ b/odb.h
> > @@ -475,6 +475,23 @@ typedef int (*odb_for_each_object_cb)(const struct object_id *oid,
> >  				      struct object_info *oi,
> >  				      void *cb_data);
> >  
> > +/*
> > + * Iterate through all objects contained in the object database. Note that
> > + * objects may be iterated over multiple times in case they are either stored
> > + * in different backends or in case they are stored in multiple sources.
> > + *
> > + * Returning a non-zero error code will cause iteration to abort. The error
> > + * code will be propagated.
> > + *
> > + * Returns 0 on success, a negative error code in case a failure occurred, or
> > + * an arbitrary non-zero error code returned by the callback itself.
> > + */
> > +int odb_for_each_object(struct object_database *odb,
> > +			struct object_info *oi,
> 
> Something I probably don't fully understand yet is the role of `struct
> object_info` being passed in here by `odb_for_each_object()` callers.
> Outside of configuring the specific object info attributes that are
> needed for a given callback, is there reason that callers would care
> about the data that gets populated in it? I was under the impression
> that this object info was really only needed for the internal
> `odb_for_eachodbject_cb` that gets invoked.

Some callers do care about this info. We see this later in the series
where they for example want to learn about the mtime of each of the
iterated objects, but we also have other cases where we want to for
example sum up the size of all objects.

Another use case for passing `struct object_info` is so that the caller
can tell apart which backend an object is coming from via the `whence`
field.

Apart from that there's also good reason to keep the current layout. For
the packfile backend for example it's significantly cheaper to iterate
and look up object info at the same time compared to iterating and then
calling `odb_read_object_info()` for each individual object. We already
have the information available when iterating, so it's just a matter of
also populating the object info with it in case the caller needs it.

Patrick