Subject: git: "git rebase -i" fails with "index.lock: File exists" every now and then
Date: Thu, 08 Jan 2015 12:15:55 +0100
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 XXXXXXX] 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 YYYYYYY... 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 libc6 2.13-38+deb7u6
ii libcurl3-gnutls 7.26.0-1+wheezy11
ii liberror-perl 0.17-1
ii libexpat1 2.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 patch 2.6.1-3
ii rsync 3.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-el <none>
pn git-email <none>
pn git-gui <none>
pn git-svn <none>
pn gitk <none>
pn gitweb <none>
-- no debconf information
Acknowledgement sent
to Sebastian Pipping <[email protected]>:
Extra info received and forwarded to list. Copy sent to Gerrit Pape <[email protected]>.
(Tue, 16 Feb 2016 12:54:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Alberto Garcia <[email protected]>:
Extra info received and forwarded to list. Copy sent to Gerrit Pape <[email protected]>.
(Mon, 06 Mar 2017 10:45:03 GMT) (full text, mbox, link).
Subject: Re: Bug#774848: git: "git rebase -i" fails with "index.lock: File
exists" every now and then
Date: Mon, 6 Mar 2017 12:42:36 +0200
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
Acknowledgement sent
to Jonathan Nieder <[email protected]>:
Extra info received and forwarded to list. Copy sent to Gerrit Pape <[email protected]>.
(Wed, 08 Mar 2017 02:30:03 GMT) (full text, mbox, link).
Subject: Re: Bug#774848: git: "git rebase -i" fails with "index.lock: File
exists" every now and then
Date: Tue, 7 Mar 2017 18:26:23 -0800
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
Acknowledgement sent
to Alberto Garcia <[email protected]>:
Extra info received and forwarded to list. Copy sent to Gerrit Pape <[email protected]>.
(Thu, 21 Sep 2017 13:39:02 GMT) (full text, mbox, link).
Subject: Re: Bug#774848: git: "git rebase -i" fails with "index.lock: File
exists" every now and then
Date: Thu, 21 Sep 2017 16:34:50 +0300
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
Acknowledgement sent
to Alberto Garcia <[email protected]>:
Extra info received and forwarded to list. Copy sent to Gerrit Pape <[email protected]>.
(Mon, 29 Jan 2018 16:09:03 GMT) (full text, mbox, link).
Subject: Re: Bug#774848: git: "git rebase -i" fails with "index.lock: File
exists" every now and then
Date: Mon, 29 Jan 2018 18:04:40 +0200
On Thu, Jan 08, 2015 at 12:15:55PM +0100, [email protected] 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
Acknowledgement sent
to Sebastian Pipping <[email protected]>:
Extra info received and forwarded to list. Copy sent to Gerrit Pape <[email protected]>.
(Mon, 29 Jan 2018 20:21:13 GMT) (full text, mbox, link).
Subject: Re: Bug#774848: git: "git rebase -i" fails with "index.lock: File
exists" every now and then
Date: Mon, 29 Jan 2018 20:48:23 +0100
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
Acknowledgement sent
to Alberto Garcia <[email protected]>:
Extra info received and forwarded to list. Copy sent to Gerrit Pape <[email protected]>.
(Tue, 30 Jan 2018 09:57:02 GMT) (full text, mbox, link).
Subject: Re: Bug#774848: git: "git rebase -i" fails with "index.lock: File
exists" every now and then
Date: Tue, 30 Jan 2018 10:34:34 +0100
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