Stefan Beller <sbel...@google.com> writes: > On Fri, Feb 13, 2015 at 10:05 AM, Junio C Hamano <gits...@pobox.com> wrote: > >> 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?
I was not talking about HEAD in what you are responding to, though. Don't we maintain a reflog on refs/remotes/origin/HEAD? Is it OK to allow its entries to become inconsistent with the underlying ref? -- 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
