ref_transaction_commit: bail out on failure to remove a ref
commit65732845e89eee69422b725bb495f4282065284f
authorJonathan Nieder <jrnieder@gmail.com>
Fri, 29 Aug 2014 00:01:35 +0000 (28 17:01 -0700)
committerJunio C Hamano <gitster@pobox.com>
Wed, 15 Oct 2014 17:47:27 +0000 (15 10:47 -0700)
tree8758012690d6d04525fcf910ac9413e0a26d72b3
parentfb43bd1cd187bcd29312df3b0394a457d524906d
ref_transaction_commit: bail out on failure to remove a ref

When removal of a loose or packed ref fails, bail out instead of
trying to finish the transaction.  This way, a single error message
can be printed (instead of multiple messages being concatenated by
mistake) and the operator can try to solve the underlying problem
before there is a chance to muck things up even more.

In particular, when git fails to remove a ref, git goes on to try to
delete the reflog.  Exiting early lets us keep the reflog.

When git succeeds in deleting a ref A and fails to remove a ref B, it
goes on to try to delete both reflogs.  It would be better to just
remove the reflog for A, but that would be a more invasive change.
Failing early means we keep both reflogs, which puts the operator in a
good position to understand the problem and recover.

A long term goal is to avoid these problems altogether and roll back
the transaction on failure.  That kind of transactionality will have
to wait for a later series (the plan for which is to make all
destructive work happen in a single update of the packed-refs file).

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Reviewed-by: Ronnie Sahlberg <sahlberg@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
refs.c