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 2/4] repository: add core.indexLockTimeout
Date: Sat, 17 Oct 2026 00:32:29 -0700 [thread overview]
Message-ID: <20261017073231.3357477-3-quark.zju@gmail.com> (raw)
In-Reply-To: <20261017073231.3357477-1-quark.zju@gmail.com>
From: Jun Wu <quark@meta.com>
Make "git add/rm/checkout" wait for the index lock, so they won't fail
immediately.
When an IDE runs "git status" every 5 seconds, and each "git status" holds the
index lock for 0.5s, a user has 10% chance to be unable to commit or checkout.
By waiting, the add and checkout commands can succeed.
Example commands that will wait:
- add, rm, mv, checkout / switch / restore, read-tree, apply --index /
--cached, update-index, cherry-pick, revert, clone.
Example commands that are unchanged:
- repo_try_hold_locked_index() users (see previous commit):
status, describe --dirty, part of diff / merge / rebase.
- repo_hold_locked_index() users, but racy (waiting makes race worse,
see code comment for details): stash, part of merge, am,
add -i / -p, checkout-index, sparse-checkout, rerere,
commit (until the next commit), reset (until a later commit).
Default timeout is 1s. Mercurial uses 600s. In case of an unexpected
use-case with unexpected expectation, I picked a conservative middle
ground.
Some tests emulate the index lock being taken, the new behavior makes
those tests slower (but still passing). Those tests now set timeout to 0
to run as fast as before.
Alternatively, IDEs could use "git --no-optional-locks status" to avoid taking
the index lock. However, not all tool authors know about "--no-optional-locks",
and "--no-optional-locks" will lose the refreshed stat info, so later
(periodical) "git --no-optional-locks status" runs become slower over time
(assuming nothing refreshes the index).
Signed-off-by: Jun Wu <quark@meta.com>
---
Documentation/config/core.adoc | 6 +++++
repository.c | 26 +++++++++++++++++++-
repository.h | 4 ++++
t/meson.build | 1 +
t/t0031-lockfile-pid.sh | 4 ++++
t/t0032-index-lock-timeout.sh | 43 ++++++++++++++++++++++++++++++++++
t/t7400-submodule-basic.sh | 1 +
7 files changed, 84 insertions(+), 1 deletion(-)
create mode 100755 t/t0032-index-lock-timeout.sh
diff --git a/Documentation/config/core.adoc b/Documentation/config/core.adoc
index bdc74d291c..88f3529cc0 100644
--- a/Documentation/config/core.adoc
+++ b/Documentation/config/core.adoc
@@ -604,6 +604,12 @@ core.configLockTimeout::
that is already on disk before the lock is taken, so it can be
set persistently like any other option.
+core.indexLockTimeout::
+ The length of time, in milliseconds, to retry when trying to
+ lock the index file for writing. Value 0 means not to retry at
+ all; -1 means to try indefinitely. Default is 1000 (i.e., retry
+ for 1 second). Not supported by all commands.
+
core.pager::
Text viewer for use by Git commands (e.g., 'less'). The value
is meant to be interpreted by the shell. The order of preference
diff --git a/repository.c b/repository.c
index a74b1118cb..c7d098d166 100644
--- a/repository.c
+++ b/repository.c
@@ -473,9 +473,33 @@ int repo_hold_locked_index(struct repository *repo,
struct lock_file *lf,
int flags)
{
+ int timeout_ms;
+
if (!repo->index_file)
BUG("the repo hasn't been setup");
- return repo_hold_lock_file_for_update(repo, lf, repo->index_file, flags);
+
+ if (repo->index->initialized) {
+ /*
+ * Index was read before lock. Depending on the callsite
+ * logic, the write might be racy:
+ *
+ * - read: repo_read_index()
+ * - lock: repo_hold_locked_index() -> maybe sleep()
+ * - write: repo_update_index_if_able() # okay
+ * write_locked_index() # racy, worse with sleep()
+ *
+ * Be conservative, avoid sleep() to not make the write race
+ * worse. If the callsite wants the "waiting for index lock"
+ * behavior, fix the read/lock order.
+ */
+ timeout_ms = 0;
+ } else {
+ timeout_ms = 1000;
+ repo_config_get_int(repo, "core.indexlocktimeout", &timeout_ms);
+ }
+
+ return repo_hold_lock_file_for_update_timeout(repo, lf, repo->index_file,
+ flags, timeout_ms);
}
int repo_try_hold_locked_index(struct repository *repo,
diff --git a/repository.h b/repository.h
index 253a5f1d3f..fe4eedd7d3 100644
--- a/repository.h
+++ b/repository.h
@@ -284,6 +284,10 @@ void repo_clear(struct repository *repo);
* populated then the number of entries will simply be returned.
*/
int repo_read_index(struct repository *repo);
+
+/*
+ * Obtain the index lock. This can block (retry with backoff).
+ */
int repo_hold_locked_index(struct repository *repo,
struct lock_file *lf,
int flags);
diff --git a/t/meson.build b/t/meson.build
index 11b3752f00..3aff2a9f50 100644
--- a/t/meson.build
+++ b/t/meson.build
@@ -108,6 +108,7 @@ integration_tests = [
't0029-core-unsetenvvars.sh',
't0030-stripspace.sh',
't0031-lockfile-pid.sh',
+ 't0032-index-lock-timeout.sh',
't0033-safe-directory.sh',
't0034-root-safe-directory.sh',
't0035-safe-bare-repository.sh',
diff --git a/t/t0031-lockfile-pid.sh b/t/t0031-lockfile-pid.sh
index e9e2f04049..3fc8de02b6 100755
--- a/t/t0031-lockfile-pid.sh
+++ b/t/t0031-lockfile-pid.sh
@@ -8,6 +8,10 @@ The feature is opt-in via core.lockfilePid config setting (boolean).
. ./test-lib.sh
+test_expect_success 'setup' '
+ git config --global core.indexLockTimeout 0
+'
+
test_expect_success 'stale lock detected when PID is not running' '
git init repo &&
(
diff --git a/t/t0032-index-lock-timeout.sh b/t/t0032-index-lock-timeout.sh
new file mode 100755
index 0000000000..cde6f1892c
--- /dev/null
+++ b/t/t0032-index-lock-timeout.sh
@@ -0,0 +1,43 @@
+#!/bin/sh
+
+test_description='Test config core.indexLockTimeout'
+
+. ./test-lib.sh
+
+prepare_index_lock () {
+ test_when_finished "rm -f .git/index.lock" &&
+ touch .git/index.lock &&
+ {
+ ( sleep 1 && rm -f .git/index.lock ) &
+ } &&
+ test_when_finished "wait"
+}
+
+test_must_fail_with_index_lock () {
+ test_must_fail "$@" 2>err &&
+ test_grep index.lock err
+}
+
+test_expect_success 'index locked, add fails with indexLockTimeout=0' '
+ prepare_index_lock &&
+ touch foo &&
+ test_must_fail_with_index_lock git -c core.indexLockTimeout=0 add foo
+'
+
+test_expect_success 'index locked, add waits with indexLockTimeout>0' '
+ prepare_index_lock &&
+ git -c core.indexLockTimeout=5000 add foo
+'
+
+test_expect_success 'index locked, commit fails even with indexLockTimeout>0 (read index before lock)' '
+ prepare_index_lock &&
+ test_must_fail_with_index_lock git -c core.indexLockTimeout=5000 commit -m init
+'
+
+test_expect_success 'index locked, checkout waits with indexLockTimeout>0' '
+ git commit -m init &&
+ prepare_index_lock &&
+ git -c core.indexLockTimeout=5000 checkout HEAD
+'
+
+test_done
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index eefdecb0bd..9a90b6a76d 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -276,6 +276,7 @@ test_expect_success 'submodule add to reconfigure existing submodule with --forc
'
test_expect_success 'submodule add relays add --dry-run stderr' '
+ test_config_global core.indexLockTimeout 0 &&
test_when_finished "rm -rf addtest/.git/index.lock" &&
(
cd addtest &&
--
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 ` [PATCH v2 0/4] Wait for the index lock instead of failing Jun Wu
2026-10-17 7:32 ` [PATCH v2 1/4] repository: add repo_try_hold_locked_index() Jun Wu
2026-10-17 7:32 ` Jun Wu [this message]
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-3-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