git index.lock error: retrying without duplicate writes

Problem Context

When multiple Git processes attempt to modify the index simultaneously, Git creates an .git/index.lock file. If a second process starts while the lock exists, Git aborts with the message fatal: Unable to create '.git/index.lock': File exists. The goal is to retry the operation after the lock is released, but without re‑writing the same objects or duplicating work that may have already been performed by the first process.

Constraints & Uncertainty

• The lock file is created atomically, but on NFS systems its visibility can be delayed, leading to false positives.
• Stale index.lock files may persist if a process crashes, requiring manual removal or a special flag.
• Git does not expose a built‑in retry mechanism that avoids re‑executing the same write operations.

Unresolved Questions

1. Does Git provide a documented flag or configuration that automatically waits for index.lock to be released and then retries the operation without re‑creating objects?

2. If no such flag exists, what is the recommended pattern for safely retrying an index‑modifying command while ensuring idempotency and avoiding duplicate writes?

3. How does NFS‑specific locking behavior affect the reliability of index.lock and what mitigations are documented in Git’s official guidance?