From: Stefan Beller Date: Wed, 11 Feb 2015 23:25:38 GMT Subject: Re: [PATCH 8/8] reflog_expire(): lock symbolic refs themselves, not their referent Message-ID: In-Reply-To: On Wed, Feb 11, 2015 at 2:49 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> On Mon, Feb 9, 2015 at 1:12 AM, Michael Haggerty wrote: >>> 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. That makes sense! Do we have documentation on symrefs? Originally I was wondering if this would make things complicated for symbolic branches which are not HEAD. Then you could update the branch pointed to, because it has no lock as the lock is on the symref. On the other hand this seems to be an improvement, as you cannot move the symref itself, as it has the lock and we don't really have other symrefs?