On Fri, Feb 13, 2015 at 10:26 AM, Junio C Hamano <gits...@pobox.com> wrote: > 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? >
Yes we do have a HEAD ref log, and that ref log would differ from the underlying ref log. I don't know if that is desired, but I would tend to not like it. So the other party updating the underlying ref would also need to lock HEAD then, which ... they don't. But they try writing to it nevertheless, in refs.c line 3121-3150 see the /* special hack */ comment. -- 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
