git index.lock error: retrying without duplicate writes

Direct answer

No. Modern Git (2.x) does not expose a documented flag or configuration that waits for .git/index.lock to clear and then automatically retries an index-modifying command. Settings such as core.filesRefLockTimeout govern reference locks, not the index lock, and --no-optional-locks only suppresses optional refreshes. You must serialize writers yourself or wrap the command in a bounded retry loop.

What actually happened

Likely explanation: two Git processes raced to create .git/index.lock. The first succeeded; the second saw the file and aborted before touching the index. That abort alone does not mean objects were duplicated. Git objects are content-addressed, so re-running git add for the same paths after the lock clears normally creates no new blobs, and the index simply converges to the last writer's state.

Confirmed risk: the real duplicate-work danger is commits. If another process already committed while your process was blocked, a blind retry can produce an empty commit or a redundant one. The index write is cheap to repeat; the commit is not.

Safe retry pattern

Serialize every index writer for the repository with an external guard lock. Do not use .git/index.lock itself as the guard—deleting or reusing it can corrupt the index. A separate flock around the Git command is the portable baseline:

flock .git/guard.lock git add -A
flock .git/guard.lock git commit -m "apply changes"

If you cannot hold a global lock, use only a bounded backoff loop around lock acquisition. Wait while the lock file exists, then re-check repository state before re-running the write:

while [ -e .git/index.lock ]; do sleep 1; done
git --no-optional-locks add -A
git rev-parse HEAD > /tmp/head.before
git diff --cached --quiet || echo "staged changes present"
git --no-optional-locks commit -m "apply changes" || true

After any retry, compare git rev-parse HEAD and git diff --cached against pre-retry values. If HEAD is unchanged and the index is clean, treat the work as already done. Do not add --allow-empty unless empty commits are intentional.

NFS and stale locks

On NFS, index.lock relies on atomic exclusive-create semantics that client caching can delay or violate. The lock may be invisible to a second client or falsely reported as present. There is no index-specific NFS retry knob; the documented-safe mitigation is a single writer or a reliable lock mechanism outside Git.

Git does not auto-clear stale index.lock files. Remove one only after confirming no live Git process is using the repository—otherwise deleting a live lock can corrupt the index.

Verification and next step

To confirm the behavior in your environment, run two concurrent git add processes in a scratch repository and verify the second fails with the expected message. Then check whether core.filesRefLockTimeout is set and confirm it does not affect the index lock in your Git version.

One missing detail changes the recommendation: is your repository on a local disk or a network mount such as NFS? On local disk, the flock wrapper is usually sufficient. On NFS, you should treat the repository as single-writer or move the lock to a reliable external service.