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

[Duy Nguyen <pclouds@gmail.com>]

On Thu, May 2, 2019 at 11:58 PM Jeff King <peff@peff.net> wrote:
> > 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