Re: [PATCH 0/2] status: stop holding index.lock while collecting

[Jun Wu <quark.zju@gmail.com>]

Hi Junio,

On Fri, 23 Oct 2026 11:33:12 -0700, Junio C Hamano wrote:
> Mihai Cosma <mcosma@gmail.com> writes:
>
> > This overlaps with Jun Wu's "Wait for the index lock instead of
> > failing" series, and the two fit together: his makes writers wait for
> > the lock, this makes status hold it rarely and briefly. They only
> > conflict on the one lock call in cmd_status(), which his series renames
> > to repo_try_hold_locked_index(). I'm happy to rebase onto it. On top of
> > his v2, the slowest "git add" in the clean case below went from 1020 ms
> > (one failure at his 1s timeout) to 160 ms.
>
> Perhaps you two can work together and send a single consolidated series?

I think the two series are relatively independent:
- Mine changed non-status commands.
- Mihai's mainly changed "status".

Neither series replaces any part of the other.

There are multiple subtle pre-existing race conditions involved:
- I fixed some read/lock wrong order races.
- Mihai fixed a update_index_if_able() race when skipHash=true.
  (This alone could go to maint.)

My preference is to keep them separate to bound the mental complexity
needed to understand related issues. The actual textual conflict is just
one function name.

-Jun