Re: [PATCH v6 3/3] rerere: go on at a conflict when the lock stays busy

From: Thomas Bachem <mail@thomasbachem.com>
Date: Oct 10, 2026, 09:09 UTC
Message-ID: <CAA0xjtpWELRcptFbY4D8f4s1erhHiZeh4xfEC--nYw9fVu_QLw@mail.gmail.com>
In-Reply-To: <asiuemA6ouAW9NXy@pks.im>

Hi Patrick,

On 09/10/2026 11:06, Patrick Steinhardt wrote:

Show 6 quoted lines

> Is this a commit that we maybe want to defer to a later point in time?
> I'm not yet convinced that it's really necessary with the other changes
> that you've done, and it feels fishy to me to just skip some operations.
> So I'd propose that we drop the commit for now, but keep the option open
> to reintroduce it at a later point in time in case where we have users
> actually hit the issue in the wild.

Agreed, I'll drop it in v7. With the wait, a rebase only dies at a conflict when another process holds the lock for longer than rerere.lockTimeout. And since tb/rerere-lock-grace, a rebase's own commits no longer start auto maintenance. If users do hit it, I'll bring the patch back.

Thanks, Thomas