Re: [PATCH 10/14] treewide: drop uses of `for_each_{loose,packed}_object()`

> On 26/01/16 08:03AM, Patrick Steinhardt wrote:
> > On Thu, Jan 15, 2026 at 03:44:50PM -0600, Justin Tobler wrote:
> > > On 26/01/15 12:04PM, Patrick Steinhardt wrote:
> > > > diff --git a/builtin/cat-file.c b/builtin/cat-file.c
> > > > index 6964a5a52c..7d16fbc1b8 100644
> > > > --- a/builtin/cat-file.c
> > > > +++ b/builtin/cat-file.c
> > > > @@ -861,8 +871,14 @@ static void batch_each_object(struct batch_options *opt,
> > > >  						&payload, flags);
> > > >  		}
> > > >  	} else {
> > > > -		for_each_packed_object(the_repository, batch_one_object_packed,
> > > > -				       &payload, flags);
> > > > +		struct object_info oi = { 0 };
> > > > +
> > > > +		for (source = the_repository->objects->sources; source; source = source->next) {
> > > > +			int ret = packfile_store_for_each_object(source->packfiles, &oi,
> > > > +								 batch_one_object_oi, &payload, flags);
> > > > +			if (ret)
> > > > +				break;
> > > > +		}
> > > 
> > > Huh, I was a bit surprised to see that we are still handling object
> > > iteration in a backend specific banner here. I would assume ideally we
> > > would want to transparently iterate across objects wherever possible. I
> > > assume the reason here has something to do with how iteration is handled
> > > with bitmaps?
> > 
> > Exactly. I was pondering a bit over whether or not I should invest a bit
> > more time to also make this part here generic. But I felt like the patch
> > series was already long enough, so I decided to not pursue this for now.
> > 
> > It's certainly something to iterate on in the future though.
> 
> Certainly not worth rerolling by itself, but it might be nice to explain
> this in the commit message and/or comment. :)