From: Jun Wu <quark.zju@gmail.com>
To: git@vger.kernel.org
Cc: gitster@pobox.com, peff@peff.net, ps@pks.im, Jun Wu <quark@meta.com>
Subject: [PATCH v2 0/4] Wait for the index lock instead of failing
Date: Sat, 17 Oct 2026 00:32:27 -0700 [thread overview]
Message-ID: <20261017073231.3357477-1-quark.zju@gmail.com> (raw)
In-Reply-To: <20261013172315.2997446-1-quark.zju@gmail.com>
From: Jun Wu <quark@meta.com>
When another process holds the index lock, commands like "git add",
"git checkout" and "git commit" fail immediately, causing user
frustration. This series lets commands that must write the index to wait
briefly for the index lock (core.indexLockTimeout, default 1s), to be
more user friendly.
"another process that holds the index lock" is often "git status" run
periodically by an IDE, or a tool. Today, such tools have 2 choices:
- "git status": risks making "checkout", "commit" fail more often.
- "git --no-optional-locks status": because "status" no longer writes
the refreshed stat info, "git --no-optional-locks status" will become
slower and slower over time, assuming no other commands refresh the
index.
This series aims for the end state that:
- Tool authors can use background "git status" just fine, and "status"
won't become slower. They can still use "--no-optional-locks", with
no behavior changes.
- End users can run "git commit/checkout" just fine, without seeing
command failures due to the index lock.
Conservatively, the new wait behavior disables itself for commands with
write race (typically "read (index) -> lock -> (no reload) -> write"),
so those racy commands stay unchanged, instead of getting a larger race
window (between "read" and "lock"). This series fixes the write races
for "commit" and "reset" so the two commands, together with other
commands that already properly lock before reading, all get the new
wait behavior. The trade-off is that "commit" now lstat() the working
tree under the index lock.
Changes since v1:
- Explain details more clearly.
- New patch 1: make "git status"'s non-waiting behavior explicit.
- New patch 4: fix "reset" write race, similar to "commit".
- Patch 3 and 4: use "write race" as motivation.
Jun Wu (4):
repository: add repo_try_hold_locked_index()
repository: add core.indexLockTimeout
commit: fix write race
reset: fix write race
Documentation/config/core.adoc | 6 +++++
builtin/commit.c | 11 +++------
builtin/describe.c | 4 ++--
builtin/diff.c | 2 +-
builtin/merge.c | 2 +-
builtin/rebase.c | 2 +-
builtin/reset.c | 7 +++---
repository.c | 33 ++++++++++++++++++++++++++
repository.h | 11 +++++++++
sequencer.c | 2 +-
t/meson.build | 1 +
t/t0031-lockfile-pid.sh | 4 ++++
t/t0032-index-lock-timeout.sh | 42 ++++++++++++++++++++++++++++++++++
t/t7400-submodule-basic.sh | 1 +
wt-status.c | 2 +-
15 files changed, 112 insertions(+), 18 deletions(-)
create mode 100755 t/t0032-index-lock-timeout.sh
base-commit: c51408889c3b372814bc20b9431c3b74d0d268eb
--
2.56.0
next prev parent reply other threads:[~2026-10-17 7:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 17:23 [PATCH 0/2] Add a way to wait for index lock Jun Wu
2026-10-13 17:23 ` [PATCH 1/2] repository: add core.indexLockTimeout Jun Wu
2026-10-13 21:40 ` D. Ben Knoble
2026-10-14 2:38 ` Jun Wu
2026-10-14 16:29 ` D. Ben Knoble
2026-10-13 22:05 ` Junio C Hamano
2026-10-14 22:12 ` Jun Wu
2026-10-13 17:23 ` [PATCH 2/2] commit: lock index before reading Jun Wu
2026-10-14 10:04 ` Jeff King
2026-10-15 0:19 ` Jun Wu
2026-10-13 22:05 ` [PATCH 0/2] Add a way to wait for index lock Junio C Hamano
2026-10-14 22:12 ` Jun Wu
2026-10-14 10:14 ` Jeff King
2026-10-17 7:32 ` Jun Wu [this message]
2026-10-17 7:32 ` [PATCH v2 1/4] repository: add repo_try_hold_locked_index() Jun Wu
2026-10-17 7:32 ` [PATCH v2 2/4] repository: add core.indexLockTimeout Jun Wu
2026-10-17 7:32 ` [PATCH v2 3/4] commit: fix write race Jun Wu
2026-10-17 7:32 ` [PATCH v2 4/4] reset: " Jun Wu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261017073231.3357477-1-quark.zju@gmail.com \
--to=quark.zju@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=ps@pks.im \
--cc=quark@meta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox