On Fri, May 05, 2023 at 06:13:57PM -0400, Jeff King wrote: > One thing that could make this a lot simpler is if the code was added to > "are we recent" code paths in the first place. > > Something like this: This is quite nice, and I think that it's a good direction to push this ~series~ patch in before queuing. That said, I wasn't sure about... > @@ -78,7 +144,7 @@ static void add_recent_object(const struct object_id *oid, > struct object *obj; > enum object_type type; > > - if (mtime <= data->timestamp) > + if (!obj_is_recent(oid, mtime, data)) > return; > > /* ...this hunk. That only kicks in if you have other recent object(s), since the hooks are consulted as a side-effect of calling your new `obj_is_recent()` function. I think in most cases that's fine, but if you had no otherwise-recent objects around, then this code wouldn't kick in in the first place. I wonder if it might make more sense to call the hooks directly in add_unseen_recent_objects_to_traversal(). > That would affect both "repack -A" and "repack --cruft". It would also > affect "git prune", but that seems like a good thing to me. I was going to say, I'm not sure this would work since we don't use any of this code from enumerate_cruft_objects() when the cruft_expiration is set to "never", but that's fine since we're keeping all of those objects anyway. OK, my bad, I think that was the point you were trying to make in your previous email, but I didn't quite grok it at the time. Yes, I agree, this code only needs to kick in when pruning. Thanks, Taylor
