Re: v2.15.0-rc2 ref deletion bug

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Oct 24, 2017, 11:05 UTC
Message-ID: <ea715dae-b410-d4fb-77c7-2e61b764a343@alum.mit.edu>
In-Reply-To: <20171024082409.smwsd6pla64jjlua@sigill.intra.peff.net>

On 10/24/2017 10:24 AM, Jeff King wrote:

Show 16 quoted lines

> 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