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
