On Thu, Jan 08, 2015 at 12:15:55PM +0100, sebast...@pipping.org wrote: > I keep running into "git rebase -i" errors on Debian wheezy. In > most cases, "git rebase --abort" and trying again works around the > problem. This is what it looks like: > > $ git rebase -i REMOTE/BRANCH > [detached HEAD XXXXXXX] MESSAGE1 > 3 files changed, 14 insertions(+), 2 deletions(-) > fatal: Unable to create '[..]/.git/index.lock': File exists.
I finally figured out what's going on. It turns out that the problem is not in git, but in Emacs. If a buffer has the auto-revert-mode enabled (see the `auto-revert-mode' variable) then Emacs will reopen it when the file changes on disk (for example during a rebase). This can in turn call `vc-find-file-hook', launching git and taking the repository lock. auto-revert-mode is disabled by default but Magit enables it in the buffers that are under version control (see magit-auto-revert-mode). I can reproduce this problem reliably if I do a git-rebase (e.g. run "git rebase -f" a few times on top of the same branch) while having some of the files affected by that rebase opened in Emacs with auto-revert-mode enabled. Here's the upstream bug report: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21559 And a related magit bug: https://github.com/magit/magit/issues/2708 Berto
