Jeff King <peff@xxxxxxxx> 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.
