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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 13, 2015, 18:26 UTC
Message-ID: <xmqqk2zloeg1.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAGZ79kZpCjcGeifbLztpNUSq7-3Yy2_GEVPGEQsxrgoZfLFU+g@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 21 quoted lines

> On Fri, Feb 13, 2015 at 10:05 AM, Junio C Hamano <gitster@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?