SUMMARY An interactive rebase (for squashing commits) just failed on me because I had the corresponding project open in KDevelop and directory changes were apparently picked up that caused git activity. STEPS TO REPRODUCE 1. ``` > git rebase -i 10d97998ded8817a610c50b764c83c71e4e46a06 ``` OBSERVED RESULT ``` fatal: Unable to create '/path/to/.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. Could not apply aeabbf1b79... Nothing to be seen here Exit 1 ``` EXPECTED RESULT No interference. In particular, I'm not expecting KDevelop to run git commands each time a file or directory change notification is received. Or rather, if something is to fail I'd expect it to be in KDevelop's git query because of the already started external git activity which triggered KDevelop's reaction. ADDITIONAL INFORMATION I'm not entirely certain how realistic my expectation is... but I'm inclined to think that it ought to be possible to obtain state (read-only) information from a repository without the need for a lock file (= in such a way that it doesn't interfere with externally triggered changes.
I still think git should fix this by not releasing the index lock between rewriting commits. You will have the same issue with e.g. a shell prompt querying the current branch if you do a long rebase operation.
Still as in this has come up before? If releasing the lock is what happens here then indeed, git is at least partly to blame. But maybe that requires a significant overhaul: I have a strong impression that git likes to call itself for subtasks. Meanwhile, could using libgit2 (in KDevelop) provide a way out here (and incidentally speed up a thing or two)?
*** This bug has been marked as a duplicate of bug 379219 ***