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
