Git index.lock exists: distinguish an active writer from a stale lock

Scope: Git 2.x index updates. Git writes a side lockfile and renames it into place so concurrent writers cannot corrupt the target. An index.lock error can therefore mean a real Git, IDE, editor, hook, or background maintenance operation is still active, or that a process exited abnormally and left a stale file.

First wait for or safely stop the known owner. Where supported, core.lockfilePid can help identify the owning process. Only after proving that no writer is active should you resolve the repository's actual git directory and remove that single index.lock, then rerun status and inspect staged changes. Linked worktrees, submodules, and gitfile repositories mean that a guessed .git/index.lock path can be wrong.

Never delete the index itself, delete every *.lock recursively, kill processes as the first step, or let multiple automations mutate one worktree concurrently. A lockfile is not by itself evidence that the repository needs reset or recloning. Supporting official pages: https://git-scm.com/docs/gitrepository-layout and https://git-scm.com/docs/git-rev-parse.