Re: [PATCH] git: add --no-optional-locks option

From: Jeff King <peff@peff.net>
Date: Sep 22, 2017, 16:04 UTC
Message-ID: <20170922160413.nbqhmszvdfrvz3u4@sigill.intra.peff.net>
In-Reply-To: <c474bf47-5049-1425-d03c-2417eb53549e@pobox.com>

On Fri, Sep 22, 2017 at 01:42:10AM -0500, Daniel Santos wrote:

Show 12 quoted lines

> > But taking the index lock may conflict with other operations
> > in the repository. Especially ones that the user is doing
> > themselves, which _aren't_ opportunistic. In other words,
> > "git status" knows how to back off when somebody else is
> > holding the lock, but other commands don't know that status
> > would be happy to drop the lock if somebody else wanted it.
> 
> Interestingly, this usually slaps me when performing an _interactive_
> rebase.  It occurred to me that if I'm performing an interaction
> operation, it doesn't seem unreasonable for git wait up to 125ms or so
> for the lock and then prompting the user to ask if they want to continue
> waiting for the lock.

Yes, lock timeouts would help with this situation, though not eliminate it entirely (and we've been adding some lock timeouts in a few places for related situations).

We generally avoid prompting, especially when a command can just be reissued. It sounds like "git rebase" gets into a funny state if it cannot grab the index lock. That's something that should be fixed. Even if it bails, you should be able to move forward with "rebase --continue" or similar.

Show 10 quoted lines

> That is not necessarily the case.  I don't actually know git on the
> inside, but I would ask you to consider a read-write lock and a hybrid
> of one and three.
> 
> I don't know what dotlocks are, but I'm certain that you can implement a
> rw lock using lock files and no other IPC, although it does increase the
> complexity.  The way this works is that `git status' acquires a read
> lock and does its thing.  If it has real changes, instead of discarding
> them it attempts to upgrade to a write lock.  If that fails, you throw
> it away, otherwise you write them and release.

By dotlocks, I just mean our strategy of creating O_EXCL "index.lock" files.

You're right that it can be done using two such locks, and communicating via the lockfile contents. So my "impossible" was overstating it. I do stand by my contention that it's much more complex than the existing scheme. :)

More importantly, though, it changes the locking contract completely between old and new versions (and between other implementations). There's probably only a small minority of users who might use two implementations to simultaneously access the same repository, but it is a use case we try to support. I think we'd have to require a repository-version bump to tell programs to use the new scheme.

-Peff