Bug#774848: git: "git rebase -i" fails with "index.lock: File exists" every now and then
On Mon, Jan 29, 2018 at 08:48:23PM +0100, Sebastian Pipping wrote: > For the record, I was not using Magit or even emacs but KWrite, > Kate, and Komodo IDE at the time. I guess one of these may have a > similar issue. Ok... well, it not only needs to reopen modified files automatically, it also needs to run git commands when it detects changes in the working directory. Berto
Bug#774848: git: "git rebase -i" fails with "index.lock: File exists" every now and then
Interesting! For the record, I was not using Magit or even emacs but KWrite, Kate, and Komodo IDE at the time. I guess one of these may have a similar issue. Best Sebastian
Bug#774848: git: "git rebase -i" fails with "index.lock: File exists" every now and then
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 XXX] 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
Bug#774848: git: "git rebase -i" fails with "index.lock: File exists" every now and then
On Tue, Mar 07, 2017 at 06:26:23PM -0800, Jonathan Nieder wrote: > >> PS: Still occurring with Git 2.1.4 of jessie. > > > > I'm having this problem very often even with the latest git from > > unstable (1:2.11.0-2). > > Thanks for writing. Please file a separate bug with details about > what steps you use to reproduce it and the exact output. If you can > get output with the GIT_TRACE environment variable set to 1, that's > even better. I'm still having problems with this once a while. I had opened a separate bug (#862895) with more information, and then I closed it when I thought that the problem had disappeared, but I still run into this every now and then. I'm using git 1:2.11.0-3+deb9u1 now. Berto
Bug#774848: git: "git rebase -i" fails with "index.lock: File exists" every now and then
Hi, Alberto Garcia wrote: > On Tue, Feb 16, 2016 at 01:51:07PM +0100, Sebastian Pipping wrote: >> PS: Still occurring with Git 2.1.4 of jessie. > > I'm having this problem very often even with the latest git from > unstable (1:2.11.0-2). Thanks for writing. Please file a separate bug with details about what steps you use to reproduce it and the exact output. If you can get output with the GIT_TRACE environment variable set to 1, that's even better. Please also check your syslog for instances of git segfaulting and include that information in your bug report. This is going to be hard to track down but it's worth the effort. It is unlikely that what you experienced has the same cause as what Sebastian experienced. The error message means that git crashed and was unable to clean up after itself --- it errors out instead of continuing because it does not know whether the other git process is still running. As an aside, it's possible git should get smarter about this and use similar locking logic to vim (check that the hostname in a lockfile matches the current hostname and then check if the process that locked the file is still running). But that's a separate story. The more urgent thing is to figure out in what scenario you have been getting git to crash. Thank you, Jonathan
Bug#774848: git: "git rebase -i" fails with "index.lock: File exists" every now and then
On Tue, Feb 16, 2016 at 01:51:07PM +0100, Sebastian Pipping wrote: > PS: Still occurring with Git 2.1.4 of jessie. I'm having this problem very often even with the latest git from unstable (1:2.11.0-2). Berto
Bug#774848: git: "git rebase -i" fails with "index.lock: File exists" every now and then
PS: Still occurring with Git 2.1.4 of jessie.
Bug#774848: git: git rebase -i fails with index.lock: File exists every now and then
Package: git Version: 1:1.7.10.4-1+wheezy1 Severity: normal 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 XXX] MESSAGE1 3 files changed, 14 insertions(+), 2 deletions(-) fatal: Unable to create '[..]/.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 YYY... MESSAGE2 $ git --version git version 1.7.10.4 What I've been doing this time, is turning one pick into an f. -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages git depends on: ii git-man 1:1.7.10.4-1+wheezy1 ii libc62.13-38+deb7u6 ii libcurl3-gnutls 7.26.0-1+wheezy11 ii liberror-perl0.17-1 ii libexpat12.1.0-1+deb7u1 ii perl-modules 5.14.2-21+deb7u2 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages git recommends: ii less 444-4 ii openssh-client [ssh-client] 1:6.0p1-4+deb7u2 ii patch2.6.1-3 ii rsync3.0.9-4 Versions of packages git suggests: ii gettext-base 0.18.1.1-9 pn git-arch none pn git-cvs none pn git-daemon-run | git-daemon-sysvinit none pn git-doc none pn git-elnone pn git-email none pn git-gui none pn git-svn none pn gitk none pn gitwebnone -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
