v2.15.0-rc2 ref deletion bug

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!

I'd expect one of:

  1. We delete "foo" before updating "foo/bar", and we end up with a
     single ref.

  2. We complain that we cannot update "foo/bar" because "foo" still
     exists.

I was hoping for (1). But in earlier releases we did (2). That makes sense because it's safer to do all updates in a transaction before doing any deletes (since if there's a simultaneous prune we'd rather see both refs present for a moment rather than neither).

But the v2.15 behavior is just buggy, and may lead to data loss (we silently lose the refs, and then a subsequent prune may lose the objects). This bisects to Michael's dc39e09942 (files_ref_store: use a transaction to update packed refs, 2017-09-08).

Curiously, it doesn't happen if you reverse the order of the entries in the transaction (which _shouldn't_ matter, since we try to process it atomically, but obviously it just tickles this bug in a funny way).

I haven't figured out if the deletion has to be a prefix of the update to trigger the bug, or if the problem is more widespread.

-Peff