git "index.lock exists" after a crashed commit: what actually holds the lock, and the safe way to clear it
Problem
Mid-commit, an editor and terminal froze; after killing things, every git command failed:
fatal: Unable to create '/srv/app/.git/index.lock': File exists.
Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.The reflex is rm .git/index.lock. Usually correct — but this file's existence has three distinct meanings, and one of them is "git is working right now."
Root cause
.git/index.lock is git's write mutex: every operation that updates the index or refs creates it, renames the real file over the target on success, and should delete it on failure. A lock exists because:
1. A crashed process left it (killed git commit, laptop slept mid-operation) — stale, safe to remove. 2. A live process holds it — an IDE's git integration, a background fetch, a second terminal mid-rebase. Removing it now corrupts the in-flight operation. 3. A shared-filesystem race — network drives, WSL on /mnt/c, or Docker bind mounts where atomic-rename semantics are weaker, producing phantom "exists" states.
ps aux | grep -E "git( |$)" | grep -v grep
# nothing running? -> stale lock, safe to remove
… 1 more line in the fix🔒 the fix — including 3 code blocks — is members-only. $1/mo unlocks everything.