From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 24 Jul 2017 21:43:46 GMT
Subject: Re: [PATCH 21/28] commit_packed_refs(): use a staging file separate from the lockfile
Message-ID: <xmqqzibtbje5.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170724171046.rcq2vqqzikto4lbi@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> On Mon, Jul 24, 2017 at 10:09:15AM -0700, Jonathan Nieder wrote:
>
>> Jeff King wrote:
>> 
>> > This seems like the correct path to me. If the existing behavior is to
>> > lock the referring symref, that seems like a violation of the lock
>> > procedure in the first place. Because if "A" points to "B", we take
>> > "A.lock" and then modify "B". But "B" may have any number of "A" links
>> > pointing to it, eliminating the purpose of the lock.
>> >
>> > I thought we already did this, though. And that modifying HEAD (which
>> > might be a symlink) required LOCK_NO_DEREF.
>> 
>> Yes, I believe the lockfile API already does so.  Since this patch
>> creates a ".new" file, not using the lockfile API, it doesn't benefit
>> from that, though.
>
> Ah, I see. This bug makes much more sense, then. And I agree doubly that
> matching the lock-code's behavior is the right thing to do.

OK.  Anybody wants to take a crack at it (it is of lower priority to
me during the -rc freeze to deal with problems in topics on 'next'
or higher)?

Thanks.