Web lists-archives.com

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

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

That's something for me to find out :)

> I think it is more common with the index to take the lock, then while
> holding it read it in fresh (possibly dumping old results), manipulate
> the result, and then write it out. For callers which make sure to
> get a fresh view _after_ taking the lock, they should be OK if taking
> the lock is delayed.
> I guess arguably any callers that aren't that careful are already
> broken, since it is a race; any delay-and-retry _could_ have happened as
> "we were too slow to see the initial lock".

I have a feeling that most operations read the index unlocked,
manipulate and only lock before writing things out. So yeah it's
probably already racy.

We could use the trailing SHA-1 to determine if the index has not
changed since last time, but then refresh-only updates would be
considered valuable while it's not. Full index comparison is way too
expensive (at least with giant repos) to even consider. I think I
start to see why nobody has done this...