From: Thomas Bachem <mail@thomasbachem.com>
Date: Sat, 10 Oct 2026 09:09:38 GMT
Subject: Re: [PATCH v6 3/3] rerere: go on at a conflict when the lock stays busy
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:
> 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