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

[Jeff King <peff@peff.net>]

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

> > 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.

> 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