Re: [PATCH v2 6/8] rerere: provide function to collect stale entries

From: Patrick Steinhardt <ps@pks.im>
Date: May 5, 2025, 07:22 UTC
Message-ID: <aBhnOiHgfycVJhHQ@pks.im>
In-Reply-To: <xmqqwmazug0i.fsf@gitster.g>

On Fri, May 02, 2025 at 09:35:57AM -0700, Junio C Hamano wrote:

Show 9 quoted lines

> Patrick Steinhardt <ps@pks.im> writes:
> > We could also adapt this to be closer to the original version, where we
> > only verified that ".git/rr-cache" exists and contains at least one
> > subdirectory. This can even be combined with the above approach if we
> > set "maintenance.rerere-gc.auto=1" by default.
> 
> But wouldn't that be like always running "rerere gc"?  What would
> you save by checking the existence of at least one rerere entry?
> Cost to spawn "rerere gc" as a subprocess?

What you save is executing the rerere logic in case the feature isn't enabled at all, but also in the case where you have eventually disabled the rerere cache but still have a now-empty ".git/rr-cache" directory.

> Wouldn't it be a better use of the engineering effort to libify the
> logic of that process and make it internally callable in the longer
> term (or are you already doing that in this series)?

The logic itself already is quite encapsulated, but I decided to not use it for now because we don't do so for any of the other tasks, either. But I do agree that we should eventually refactor all of our tasks so that they don't need to spawn an external process at all.

Patrick