Re: [PATCH 8/8] reflog_expire(): lock symbolic refs themselves, not their referent

From
Junio C Hamano <hidden>
Date
2016-06-15 23:03:47
Stefan Beller [off-list ref] writes:
On Mon, Feb 9, 2015 at 1:12 AM, Michael Haggerty [off-list ref] wrote:
quoted
When processing the reflog of a symbolic ref, hold the lock on the
symbolic reference itself, not on the reference that it points to.
I am not sure if that makes sense.
So when expiring HEAD, you want to have a .git/HEAD.lock file
instead of a .git/refs/heads/master.lock file?

What would happen if there is a concurrent modification
to the master branch?
The HEAD may be pointing at 'master' and the other party that is
trying to modify it would fail when it tries to update the reflog
for HEAD thanks to HEAD.lock being held by us.  The HEAD may be
pointing at 'next' and the other part that updates 'master' would
not try to modify HEAD reflog and we do not conflict.

At least, I think that is the rationale behind this change.
Thread (6 messages) 6 messages, 3 authors, last reply 2016-06-15
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help