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
next prev parent 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