Hi, 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. Thanks, Jonathan
