Git development
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Derrick Stolee <stolee@gmail.com>
Cc: git@vger.kernel.org, Thomas Bachem <mail@thomasbachem.com>,
	Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH 1/2] rerere: extract logic to determine whether entries are stale
Date: Fri, 4 Sep 2026 07:21:15 +0200	[thread overview]
Message-ID: <appVS2P6ThaRU9fc@pks.im> (raw)
In-Reply-To: <a63c3bbe-28b8-4026-9c07-11c2d445c504@gmail.com>

On Thu, Sep 03, 2026 at 10:11:20AM -0400, Derrick Stolee wrote:
> On 9/3/2026 5:04 AM, Patrick Steinhardt wrote:
> > When garbage collecting rerere entries we need to figure out whether any
> > given entry is stale before pruning it. In a subsequent commit we're
> > about to introduce a second caller that wants to determine staleness,
> > but the logic is not currently reusable.
> > 
> > Extract the logic to compute staleness by introducing two new helper
> > functions `rerere_gc_cutoffs()` and `rerere_id_is_stale()`.
> 
> Thanks for doing these extractions. It reduces complexity in the top-
> level logic.
> 
> > -static void prune_one(struct rerere_id *id,
> > -		      timestamp_t cutoff_resolve, timestamp_t cutoff_noresolve)
> ...> +static bool rerere_id_is_stale(struct rerere_id *id,
> > +			       timestamp_t cutoff_resolve,
> > +			       timestamp_t cutoff_noresolve)
> 
> This modification of prune_one() to a staleness check is good to
> have split, but...
> 
> >  		for (id.variant = 0, id.collection = rr_dir;
> >  		     id.variant < id.collection->status_nr;
> >  		     id.variant++) {
> > -			prune_one(&id, cutoff_resolve, cutoff_noresolve);
> > +			if (rerere_id_is_stale(&id, cutoff_resolve, cutoff_noresolve))
> > +				unlink_rr_item(&id);
> >  			if (id.collection->status[id.variant])
> >  				now_empty = 0;
> >  		}
> 
> ...this loop gets slightly more complicated. This is not worth
> a change, but I'm thinking out loud that I would have updated
> prune_one to be this simple:
> 
> static void prune_one(struct rerere_id *id,
> 		      timestamp_t cutoff_resolve, timestamp_t cutoff_noresolve)
> {
> 	if (rerere_id_is_stale(&id, cutoff_resolve, cutoff_noresolve))
> 		unlink_rr_item(&id);
> } 
> and left the loop alone. This is only a preference, as your
> implementation is also quite clean.

That's fair. I originally retained `prune_one()`, but then I wasn't sure
whether it's really worth it anymore given that it's essentially a
two-line function now. Anyway, will restore it.

Patrick

  reply	other threads:[~2026-09-04  5:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-03  9:04 [PATCH 0/2] builtin/maintenance: improve heuristic for "rerere gc" Patrick Steinhardt
2026-09-03  9:04 ` [PATCH 1/2] rerere: extract logic to determine whether entries are stale Patrick Steinhardt
2026-09-03 14:11   ` Derrick Stolee
2026-09-04  5:21     ` Patrick Steinhardt [this message]
2026-09-03  9:04 ` [PATCH 2/2] builtin/maintenance: improve heuristic for "rerere gc" Patrick Steinhardt
2026-09-03 14:19   ` Derrick Stolee
2026-09-04  5:21     ` Patrick Steinhardt
2026-09-03 12:12 ` [PATCH 0/2] " Thomas Bachem
2026-09-04  7:03 ` [PATCH v2 " Patrick Steinhardt
2026-09-04  7:03   ` [PATCH v2 1/2] rerere: extract logic to determine whether entries are stale Patrick Steinhardt
2026-09-04  7:03   ` [PATCH v2 2/2] builtin/maintenance: improve heuristic for "rerere gc" Patrick Steinhardt
2026-09-04 13:51   ` [PATCH v2 0/2] " Derrick Stolee
2026-09-04 14:48   ` Junio C Hamano
2026-09-04 16:14     ` Junio C Hamano
2026-09-04 16:53       ` Thomas Bachem
2026-09-07  6:15         ` Patrick Steinhardt
2026-09-07  6:15     ` Patrick Steinhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=appVS2P6ThaRU9fc@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=mail@thomasbachem.com \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=stolee@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox