Re: [PATCH 21/28] commit_packed_refs(): use a staging file separate from the lockfile

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Jul 26, 2017, 23:49 UTC
Message-ID: <CAMy9T_Hj5sYwwoA4mBZFbUmriAzSaW4VWYwB3F-3DQ-6UpBU3A@mail.gmail.com>
In-Reply-To: <xmqqzibtbje5.fsf@gitster.mtv.corp.google.com>

I just submitted a patch [1] that fixes the `packed-refs`-is-a-symlink problem in combination with git-new-workdir.

I haven't considered any possible problems related to `core.preferSymlinkRefs`. That behavior should be unaffected by the packed-ref-store patch series and I'm not very interested in working on it.

Michael

[1] https://public-inbox.org/git/d0da02a8b6f0272fa70ae3b1dc80fee6c6ee8d18.1501111803.git.mhagger@alum.mit.edu/

On Mon, Jul 24, 2017 at 2:43 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 27 quoted lines

> 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.