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