From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Thomas Bachem <mail@thomasbachem.com>,
Derrick Stolee <stolee@gmail.com>,
Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH v2 0/2] builtin/maintenance: improve heuristic for "rerere gc"
Date: Mon, 7 Sep 2026 08:15:36 +0200 [thread overview]
Message-ID: <ap5WiLQDzqdSyzvI@pks.im> (raw)
In-Reply-To: <xmqqfqzp6pir.fsf@gitster.g>
On Fri, Sep 04, 2026 at 07:48:44AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
> > Hi,
> >
> > as reported and discussed in [1]. Thanks!
>
> Can you, and everybody else, refrain from forcing all readers to
> visit a different message to understand what it is? It does not
> help that [1] is a full description of both problem and solution
> that is not designed to be a summary to begin with, and to add
> insult to injury, it is AI slop wall of text that mistakenly thinks
> that more is better.
>
> Perhaps you could have distilled the essense down to several lines?
>
> Since Git 2.54, background maintenance triggers after a commit
> runs "git rerere gc", which acquires the MERGE_RR.lock. During
> rebase, a subsequent sequencer commit also tries to acquire this
> lock within milliseconds. Due to use of LOCK_DIE_ON_ERROR,
> whichever arrives second aborts, causing rebase failures.
>
> I'll leave it as an exercise to readers to summarize the solution
> part that this series (not the original one) proposes to make.
Fair, will adapt going forward.
Patrick
prev parent reply other threads:[~2026-09-07 6:15 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
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 [this message]
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=ap5WiLQDzqdSyzvI@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.