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

From: Taylor Blau <me@ttaylorr.com>
Date: May 6, 2023, 00:13 UTC
Message-ID: <ZFWbuf34pVxJyRiM@nand.local>
In-Reply-To: <20230505221357.GD3321533@coredump.intra.peff.net>

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...

Show 9 quoted lines

> @@ -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