Re: v2.15.0-rc2 ref deletion bug
From: Michael Haggerty <hidden>
Date: 2017-10-24 11:05:09
On 10/24/2017 10:24 AM, Jeff King wrote:
I found a potentially serious bug in v2.15.0-rc2 (and earlier release candidates, too) that we may want to deal with before the release. If I do: git init -q repo cd repo obj=$(git hash-object -w /dev/null) git update-ref refs/tags/foo $obj git update-ref --stdin <<-EOF delete refs/tags/foo update refs/tags/foo/bar $obj EOF git for-each-ref then at the end we have no refs at all!
That's a serious bug. I'm looking into it right now.
I'd expect one of:
1. We delete "foo" before updating "foo/bar", and we end up with a
single ref.
I don't think that this is possible in the general case in a single
transaction. The problem is that the code would need to take locks
refs/tags/foo.lock
refs/tags/foo/bar.lock
But the latter couldn't coexist with the loose reference file
refs/tags/foo
, which might already exist.
It is only imaginable to do this in a single transaction if you pack and
prune `refs/tags/foo` first, to get the loose reference out of the way,
before executing the transaction. Even then, you would have to beware of
a race where another process writes a loose version of `refs/tags/foo`
between the time that `pack-refs` prunes it and the time that the
transaction obtains the lock again.
[...]
Michael