Re: Bug: fatal: Unable to create '.../.git/index.lock': File exists.

From: Duy Nguyen <pclouds@gmail.com>
Date: May 3, 2019, 05:42 UTC
Message-ID: <CACsJy8AWfARPKczV7nGoBz35cBGsuNBtfh5pCFHvjBSB1_HHWg@mail.gmail.com>
In-Reply-To: <20190502165802.GA19341@sigill.intra.peff.net>

On Thu, May 2, 2019 at 11:58 PM Jeff King <peff@peff.net> wrote:

Show 9 quoted lines

> > I might take a stab at the "wait and try to hold the lock again, doing
> > necessary verification after if needed" idea. It sounds like the right
> > way to go and we haven't had problems with refs doing the same thing
> > (have we?).
>
> No, but it's a bit easier with refs because the locking is just
> atomically checking the lease. I.e., after taking the lock we still say
> "we expected the ref to be at oid XYZ, is it still there?". What's the
> equivalent for an index operation?

We could add a second hash that only covers the valuable parts (e.g. paths, stage index, SHA-1 and probably some ce_flags). This should be enough to verify if the index is still the same as before (stat info does not count, the same for other cache data like untracked cache, cache-tree...).

This will add some overhead of course because we hash more, especially on large index files. So it will be optional. The hash is stored in an extension. If you run things in parallel and want this, enable it. If the extension is not present in the first place, we don't attempt to wait and retry or anything.

-- 
Duy