On Thu, Dec 04, 2014 at 04:23:31PM -0800, Jonathan Nieder wrote: > Michael Haggerty wrote: > > > We don't actually need the locking functionality, because we already > > hold the lock on the reference itself, which is how the reflog file is > > locked. But the lock_file code still does some of the bookkeeping for > > us and is more careful than the old code here was. > > As you say, the ref lock takes care of mutual exclusion, so we do not > have to be too careful about compatibility with other tools that might > not know to lock the reflog. And this is not tying our hands for a > future when I might want to lock logs/refs/heads/topic/1 while > logs/refs/heads/topic still exists as part of the implementation of > "git mv topic/1 topic". > > Stefan and I had forgotten about that guarantee when looking at that > kind of operation --- thanks for the reminder. I did not forget about it, I did not know about that in the first hand. We don't seem to have documentation on it? So sorry for heading in a direction, which would have been avoidable. Thanks, Stefan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html