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.mhag...@alum.mit.edu/ On Mon, Jul 24, 2017 at 2:43 PM, Junio C Hamano <gits...@pobox.com> wrote: > Jeff King <p...@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.
