Subject: Re: [PATCH v2] builtin/pack-objects.c: introduce `pack.extraCruftTips`

From: Taylor Blau <[email-masked]>
Date: Fri, 5 May 2023 20:13:45 -0400

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