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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 02, 2025 at 09:35:57AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@xxxxxx> 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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux