Re: [PATCH 1/2] repository: add core.indexLockTimeout

[Ben Knoble <ben.knoble@gmail.com>]

> Le 14 oct. 2026 à 18:13, Jun Wu <quark.zju@gmail.com> a écrit :
> 
> On Tue, 13 Oct 2026 15:05:52 -0700, Junio C Hamano wrote:
>>> Default timeout is 1s, effective but not too long to avoid breaking potential
>>> user expectation (e.g. "an index.lock error means I should check whether a
>>> commit message editor is open somewhere"). Tests that are slowed down by the
>>> default timeout now set the timeout to 0.
> 
>> I am not sure if the change is making the right trade-off between
>> background tasks and end-user action that expects immediate
>> response.
> 
> It seems the trade-off is between command success rate and command duration.
> 
> I suspect that end-users want commands to work (not fail) first, performance
> comes next. In my experience, high command failure rate escalates to oncall
> incidents, occasional slightly slower commands often get unnoticed unless we
> look at the metrics explicitly.

I’ve given it some more thought, and acknowledging that 
I’m unaffected by the bug being fixed, I would add:

It seems like working flows have to become more complex 
to handle these broken flows. And that leaves a sour taste for me.
Folks do notice hangups at a shell that is typically quick to respond.

But, as I said, I’ll bow out since it seems like there’s some support
from more experienced folks for this direction.