The retry budget was five fixed 50ms waits (250ms total). A foreground
`git status` refresh can hold index.lock for longer than that on a large
repo, so the retries could be exhausted before the lock clears. Wait 20ms
before the first retry and double each time, giving seven attempts over a
bit more than a second — enough to outlast a slow refresh while keeping
the common case (a lock that clears almost immediately) fast. The initial
delay is now a runner field so tests can zero it out instead of sleeping.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The retry check matched the literal ".git/index.lock", which only ever
appears for the main worktree. A linked worktree's lock is at
.git/worktrees/<name>/index.lock and a submodule's is under its own git
dir, so contention there was never retried. Match the bare "index.lock"
fragment instead, which covers all of them.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Have isRetryableError also inspect the returned error, not just the
captured output. Streamed commands (amend, commit, and other operations
run through the gpg helper) don't capture output, so their index.lock
failures were slipping past the retry loop and surfacing to the user as
a hard "Git command failed". Now they retry like every other command.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
RunWithOutput and RunWithOutputs each carried their own near-identical
copy of the index.lock retry loop. Extract the loop into a single
retryOnLockError helper so the retry policy lives in one place, ahead of
changing that policy. Behavior is unchanged; the added tests characterize
it (success and non-lock errors run once, a lock error in the output is
retried).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Extends the existing retry logic to handle transient lock-related errors beyond just .git/index.lock. This now also retries when encountering "cannot lock ref" or "cannot update ref" errors, which can occur intermittently during fetch/pull operations in large repositories.
Related to #5124
Signed-off-by: majiayu000 <1835304752@qq.com>
I don't know why we're getting index.lock errors but they're impossile to stop
anyway given that other processes can be calling git commands. So we're retrying
a few times before re-raising. To do this we need to clone the command and the current
implementation for that is best-effort.
I do worry about the maintainability of that but we'll see how it goes.
Also, I thought you'd need to clone the task (if it exists) but now I think not;
as long as you don't call done twice on it you should be fine, and you shouldn't
be done'ing a task as part of running a command: that should happen higher up.
Stefan HallerandClaude Opus 4.8
majiayu000andStefan Haller
Jesse Duffield
Ryooooooga