From: Patrick Steinhardt Date: Mon, 19 Jan 2026 07:10:50 GMT Subject: Re: [PATCH 07/14] odb: introduce `odb_for_each_object()` Message-ID: In-Reply-To: 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