Scenario, run: $ git rebase v3.10.12 --autosquash -i And randomly get this: fatal: Unable to create '.../linux/.git/index.lock': File exists. If no other git process is currently running, this probably means a git process crashed in this repository earlier. Make sure no other git process is running and remove the file manually to continue. Could not apply .... I've noticed this happening randomly for a few years now, and always chalked it up to NFS weirdness, but I figured out what is going on today (as I am not using NFS right now).. I have emacs windows open that have files within the git tree open in them. My emacs has vc-git mode loaded and global-auto-revert-mode set. During the rebase the files open in emacs are changed by git, when emacs notices this (which is random with respect to the ongoing rebase) it auto reverts and runs git commands (due to vc-git), which causes the rebase to randomly fail. Worse, I've noticed that this also randomly seems to cause the rebase to loose a commit if you --continue from that point. Can git have some retry in the locking so this doesn't happen? Jason -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html