threads / discuss / 34940

Git rebase dies with fatal: Unable to create '.../.git/index.lock': File exists.

Subject: Git rebase dies with fatal: Unable to create '.../.git/index.lock': File exists.

## tl;dr

4 messages between Sep 16, 2013 and Sep 16, 2013.

replies: 3people: 2as markdown or json

Jason Gunthorpe· Sep 16, 2013, 18:28 UTC · lore

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

Jeff King· Sep 16, 2013, 21:15 UTC · re: Jason Gunthorpe · lore

Re: Git rebase dies with fatal: Unable to create '.../.git/index.lock': File exists.

On Mon, Sep 16, 2013 at 12:28:52PM -0600, Jason Gunthorpe wrote:

Show 12 quoted lines

> 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?

I'm not clear on which git commands are being run. If they are actually mutating the index, then isn't this more than a lock contention issue? In other words, "git rebase" is assuming nobody is mucking with the index while it runs; if emacs is doing so, then the results could be quite confusing, even if we retried the lock acquisition.

-Peff

Jason Gunthorpe· Sep 16, 2013, 21:21 UTC · re: Jeff King · lore

Re: Git rebase dies with fatal: Unable to create '.../.git/index.lock': File exists.

On Mon, Sep 16, 2013 at 05:15:01PM -0400, Jeff King wrote:

Show 20 quoted lines

> On Mon, Sep 16, 2013 at 12:28:52PM -0600, Jason Gunthorpe wrote:
> 
> > 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?
> 
> I'm not clear on which git commands are being run. If they are actually
> mutating the index, then isn't this more than a lock contention issue?
> In other words, "git rebase" is assuming nobody is mucking with the
> index while it runs; if emacs is doing so, then the results could be
> quite confusing, even if we retried the lock acquisition.

I'm not sure what commands vc-git mode in Emacs is actually running automatically, but I'd be surprised and alaramed if they were mutating command..

I agree retry on the lock is hackish, holding the lock continuously rather than release/reaquire during operation would be much stronger prevention.

Jason

Jeff King· Sep 16, 2013, 21:47 UTC · re: Jason Gunthorpe · lore

Re: Git rebase dies with fatal: Unable to create '.../.git/index.lock': File exists.

On Mon, Sep 16, 2013 at 03:21:59PM -0600, Jason Gunthorpe wrote:

Show 13 quoted lines

> > I'm not clear on which git commands are being run. If they are actually
> > mutating the index, then isn't this more than a lock contention issue?
> > In other words, "git rebase" is assuming nobody is mucking with the
> > index while it runs; if emacs is doing so, then the results could be
> > quite confusing, even if we retried the lock acquisition.
> 
> I'm not sure what commands vc-git mode in Emacs is actually running
> automatically, but I'd be surprised and alaramed if they were mutating
> command..
> 
> I agree retry on the lock is hackish, holding the lock continuously
> rather than release/reaquire during operation would be much stronger
> prevention.

If it is not mutating the index in a way that marks content to be committed, but only "refreshing" it (i.e., updating the stat cache), that should be OK. So the question there would be: what refresh strategy does emacs use? Does it do so intentionally, or is it doing so accidentally by calling a porcelain command that auto-refreshes? So again, it comes down to figuring out exactly which commands emacs is running.

-Peff