Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > I also realized that Git's current policy is probably not tenable if one > process is re-seating a symref at the same time as another process is > expiring its reflog. The "git reflog expire HEAD" might grab > "refs/heads/master.lock" then start rewriting "logs/HEAD". Meanwhile, > "git checkout foo" would grab "HEAD.lock" (not being blocked by the > "expire" process), then rewrite it to "ref: refs/heads/foo", then grab > "refs/heads/foo.lock" before updating "logs/HEAD". So both processes > could be writing "logs/HEAD" at the same time. > ... > Switching to holding only "HEAD.lock" while updating "logs/HEAD" is the > right solution,... We convinced ourselves that not locking the symref is wrong, but have we actually convinced us that not locking the underlying ref, as long as we have a lock on the symref, is safe? To protect you, the holder of a lock on refs/remotes/origin/HEAD that happens to point at refs/remotes/origin/next, from somebody who is updating the underlying refs/remotes/origin/next directly without going through the symbolic ref (e.g. receive-pack), wouldn't the other party need to find any and all symbolic refs that point at the underlying ref and take locks on them? As dereferencing a symbolic ref in the forward direction is much cheaper than in the reverse, and because you need to dereference it anyway, I wonder if we want the endgame to be "hold locks on both", not "just hold a lock on the symlink". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html