On Fri, Feb 13, 2015 at 10:05 AM, Junio C Hamano <gits...@pobox.com> wrote: > Michael Haggerty <mhag...@alum.mit.edu> 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 we're just modifying the ref log of HEAD in this case, we don't bother with where the HEAD points to. The other party may change refs/remotes/origin/next without us noticing, but we don't care here as all we do is rewriting the ref log for HEAD. If the other party were to modify HEAD (point it to some other branch, or forward the branch pointed to), they'd be expected to lock HEAD and would fail as we have the lock? > > 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". That would be the safest option indeed. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
