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

From: Jeff King <peff@peff.net>
Date: Sep 16, 2013, 21:47 UTC
Message-ID: <20130916214720.GA6195@sigill.intra.peff.net>
In-Reply-To: <20130916212159.GA16437@obsidianresearch.com>

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