git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: Derrick Stolee <stolee@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH v3 0/7] builtin/maintenance: implement missing tasks compared to git-gc(1)
Date: Mon, 5 May 2025 09:32:47 +0200	[thread overview]
Message-ID: <aBhpn3q-sgm3WjR6@pks.im> (raw)
In-Reply-To: <xmqqo6wau3fz.fsf@gitster.g>

On Fri, May 02, 2025 at 02:07:28PM -0700, Junio C Hamano wrote:
> Derrick Stolee <stolee@gmail.com> writes:
> 
> > On 5/2/2025 4:43 AM, Patrick Steinhardt wrote:
> >
> >> Changes in v3:
> >>   - Simplify the heuristic for "rerere-gc" so that we only count the
> >>     number of directory entries in ".git/rr-cache", without considering
> >>     staleness.
> >
> > The range-diff was harder to read than just re-reviewing patch 7, but I
> > think this v3 is ready to go.
> 
> I still do not think "configurable 'rerere gc' basing the decision
> on the number of existing rerere entries" adds negative value to the
> system.  If there is truly more than N active rerere entries
> currently in your repository with your workflow, such a
> configuration essentially decides to run 'rerere gc' every time (and
> without pruning enough entries to make the next 'rerere gc'
> unnecessary), and never otherwise.  It is not like pruning unneeded
> loose object files and packing the rest into a packfile, where
> running it once (even if it resulted in miniscule packfile due to
> misidentification) would remove all the loose object files, which
> makes 'repack' unneeded for some time until we accumulate more of
> them.  After 'rerere gc', you still will have rerere entries kept.
> 
> Until we can implement a meaningful automation (which may require
> changing the way rerere entries are stored on disk to help us
> cheaply tell if there truly are excessive number of no longer
> relevant rerere entries; code that we can readily borrow from
> "rerere gc" is enough, as I said), I do not think we should add
> extra code to make such a useless decision.  Instead, I would prefer
> to see a single "do we or do we not run `rerere gc`?" Boolean, until
> that happens.
> 
> Other than that, I think the series is a good addition to the
> system.  Giving finer grained control is great, and 'git maintenance'
> is a much better framework than 'git gc' to do so.

Ok, fair enough. I'll stick with the "maintenance.rerere-gc.auto"
config as integer, but will adapt it so that any positive value will
cause us to invoke `git rerere gc` when the "rr-cache" directory exists
and has at least one entry.

The reason I want to keep it as an integer is mostly to stay consistent
with all the other "maintenance.*.auto" settings, even though it does
not add a lot of value right now.

Patrick

  reply	other threads:[~2025-05-05  7:32 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-25  7:29 [PATCH 0/7] builtin/maintenance: implement missing tasks compared to git-gc(1) Patrick Steinhardt
2025-04-25  7:29 ` [PATCH 1/7] builtin/gc: fix indentation of `cmd_gc()` parameters Patrick Steinhardt
2025-04-25  7:29 ` [PATCH 2/7] builtin/gc: remove global variables where it trivial to do Patrick Steinhardt
2025-04-25  7:29 ` [PATCH 3/7] builtin/gc: move pruning of worktrees into a separate function Patrick Steinhardt
2025-04-25  7:29 ` [PATCH 4/7] worktree: expose function to retrieve worktree names Patrick Steinhardt
2025-04-25  7:29 ` [PATCH 5/7] builtin/maintenance: introduce "worktree-prune" task Patrick Steinhardt
2025-04-29 20:02   ` Derrick Stolee
2025-04-30  7:08     ` Patrick Steinhardt
2025-04-25  7:29 ` [PATCH 6/7] builtin/gc: move rerere garbage collection into separate function Patrick Steinhardt
2025-04-25  7:29 ` [PATCH 7/7] builtin/maintenance: introduce "rerere-gc" task Patrick Steinhardt
2025-04-29 20:02 ` [PATCH 0/7] builtin/maintenance: implement missing tasks compared to git-gc(1) Derrick Stolee
2025-04-30  7:08   ` Patrick Steinhardt
2025-04-30 10:25 ` [PATCH v2 0/8] " Patrick Steinhardt
2025-04-30 10:25   ` [PATCH v2 1/8] builtin/gc: fix indentation of `cmd_gc()` parameters Patrick Steinhardt
2025-04-30 10:25   ` [PATCH v2 2/8] builtin/gc: remove global variables where it trivial to do Patrick Steinhardt
2025-04-30 10:25   ` [PATCH v2 3/8] builtin/gc: move pruning of worktrees into a separate function Patrick Steinhardt
2025-04-30 10:25   ` [PATCH v2 4/8] worktree: expose function to retrieve worktree names Patrick Steinhardt
2025-04-30 10:25   ` [PATCH v2 5/8] builtin/maintenance: introduce "worktree-prune" task Patrick Steinhardt
2025-04-30 10:25   ` [PATCH v2 6/8] rerere: provide function to collect stale entries Patrick Steinhardt
2025-04-30 16:58     ` Junio C Hamano
2025-05-02  8:07       ` Patrick Steinhardt
2025-05-02 16:35         ` Junio C Hamano
2025-05-05  7:22           ` Patrick Steinhardt
2025-04-30 10:25   ` [PATCH v2 7/8] builtin/gc: move rerere garbage collection into separate function Patrick Steinhardt
2025-04-30 10:25   ` [PATCH v2 8/8] builtin/maintenance: introduce "rerere-gc" task Patrick Steinhardt
2025-04-30 10:37   ` [PATCH v2 0/8] builtin/maintenance: implement missing tasks compared to git-gc(1) Derrick Stolee
2025-05-02  8:43 ` [PATCH v3 0/7] " Patrick Steinhardt
2025-05-02  8:43   ` [PATCH v3 1/7] builtin/gc: fix indentation of `cmd_gc()` parameters Patrick Steinhardt
2025-05-02  8:43   ` [PATCH v3 2/7] builtin/gc: remove global variables where it trivial to do Patrick Steinhardt
2025-05-02  8:44   ` [PATCH v3 3/7] builtin/gc: move pruning of worktrees into a separate function Patrick Steinhardt
2025-05-02  8:44   ` [PATCH v3 4/7] worktree: expose function to retrieve worktree names Patrick Steinhardt
2025-05-05  8:42     ` Eric Sunshine
2025-05-07  7:06       ` Patrick Steinhardt
2025-05-02  8:44   ` [PATCH v3 5/7] builtin/maintenance: introduce "worktree-prune" task Patrick Steinhardt
2025-05-05  8:59     ` Eric Sunshine
2025-05-07  7:06       ` Patrick Steinhardt
2025-05-02  8:44   ` [PATCH v3 6/7] builtin/gc: move rerere garbage collection into separate function Patrick Steinhardt
2025-05-02  8:44   ` [PATCH v3 7/7] builtin/maintenance: introduce "rerere-gc" task Patrick Steinhardt
2025-05-02 14:57   ` [PATCH v3 0/7] builtin/maintenance: implement missing tasks compared to git-gc(1) Derrick Stolee
2025-05-02 21:07     ` Junio C Hamano
2025-05-05  7:32       ` Patrick Steinhardt [this message]
2025-05-05  8:51 ` [PATCH v4 " Patrick Steinhardt
2025-05-05  8:51   ` [PATCH v4 1/7] builtin/gc: fix indentation of `cmd_gc()` parameters Patrick Steinhardt
2025-05-05  8:51   ` [PATCH v4 2/7] builtin/gc: remove global variables where it trivial to do Patrick Steinhardt
2025-05-06  7:44     ` Christian Couder
2025-05-07  7:06       ` Patrick Steinhardt
2025-05-05  8:51   ` [PATCH v4 3/7] builtin/gc: move pruning of worktrees into a separate function Patrick Steinhardt
2025-05-06  7:50     ` Christian Couder
2025-05-07  7:06       ` Patrick Steinhardt
2025-05-05  8:51   ` [PATCH v4 4/7] worktree: expose function to retrieve worktree names Patrick Steinhardt
2025-05-06  8:20     ` Christian Couder
2025-05-06 16:08       ` Eric Sunshine
2025-05-05  8:51   ` [PATCH v4 5/7] builtin/maintenance: introduce "worktree-prune" task Patrick Steinhardt
2025-05-06  7:40     ` Christian Couder
2025-05-07  7:06       ` Patrick Steinhardt
2025-05-05  8:51   ` [PATCH v4 6/7] builtin/gc: move rerere garbage collection into separate function Patrick Steinhardt
2025-05-06  8:39     ` Christian Couder
2025-05-05  8:51   ` [PATCH v4 7/7] builtin/maintenance: introduce "rerere-gc" task Patrick Steinhardt
2025-05-06  9:05   ` [PATCH v4 0/7] builtin/maintenance: implement missing tasks compared to git-gc(1) Christian Couder
2025-05-07  7:21 ` [PATCH v5 0/6] " Patrick Steinhardt
2025-05-07  7:21   ` [PATCH v5 1/6] builtin/gc: fix indentation of `cmd_gc()` parameters Patrick Steinhardt
2025-05-07  7:21   ` [PATCH v5 2/6] builtin/gc: remove global variables where it is trivial to do Patrick Steinhardt
2025-05-07  7:21   ` [PATCH v5 3/6] builtin/gc: move pruning of worktrees into a separate function Patrick Steinhardt
2025-05-07  7:21   ` [PATCH v5 4/6] builtin/maintenance: introduce "worktree-prune" task Patrick Steinhardt
2025-05-07  7:21   ` [PATCH v5 5/6] builtin/gc: move rerere garbage collection into separate function Patrick Steinhardt
2025-05-07  7:21   ` [PATCH v5 6/6] builtin/maintenance: introduce "rerere-gc" task 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=aBhpn3q-sgm3WjR6@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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;
as well as URLs for NNTP newsgroup(s).