Re: [PATCH 0/2] Add a way to wait for index lock

[Jeff King <peff@peff.net>]

On Tue, Oct 13, 2026 at 10:23:13AM -0700, Jun Wu wrote:

> From: Jun Wu <quark@meta.com>
> 
> An IDE that runs `git status` periodically in the background has 2
> choices. Both are suboptimal:
> - with `--no-optional-locks`: `status` becomes slower over time.

The idea of --no-optional-locks is that the user eventually does actually
run some command in the CLI that updates the index (or even via the IDE
if it's not git-status). But yeah, that isn't necessarily guaranteed.

It's possible that an IDE caller could be smarter about _sometimes_
running a normal git-status, if it's been a while. But then of course it
has to worry about what "a while" means. ;)

So I think looking at lock timeouts and retries on the other side is a
reasonable approach.

> To minimize write race, if the index is read before locking, the
> wait will be skipped, as if timeout is 0. Depending on the read/lock
> order, some commands (e.g. add, rm, mv, checkout, restore, read-tree,
> apply, update-index) respect the timeout. Some (e.g. reset, stash,
> merge, rebase, cherry-pick, am) do not. I started with the simple and
> common commands. If there is interest in other commands I can take a
> look too.

I think any problem exacerbated by the timeout was already a possible
race even without it. But it would be increasing the race window (which
is fine for racing benign commands like "git status", but probably bad
for racing "git add"; see my response to patch 2).

I think the git-commit race, at least, has probably been there for 20+
years. It's just that nobody has really seen it in practice because
making commits tends to be a serial-ish process (as opposed to things
like receiving pushes, where big sites hit every kind of race). But it
does seem reasonable to close those races, at which point the timeout
behavior seems like a no-brainer.

-Peff