Thread (78 messages) flat view 78 messages, 4 authors, 2016-06-15

Re: [PATCH v6 11/42] tag.c: use ref transactions when doing updates

From: Jonathan Nieder <hidden>
Date: 2016-06-15 23:01:09

Ronnie Sahlberg wrote:
quoted hunk ↗ jump to hunk
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -701,11 +702,12 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
 	if (annotate)
 		create_tag(object, tag, &buf, &opt, prev, object);
 
-	lock = lock_any_ref_for_update(ref.buf, prev, 0, NULL);
-	if (!lock)
-		die(_("%s: cannot lock the ref"), ref.buf);
-	if (write_ref_sha1(lock, object, NULL) < 0)
-		die(_("%s: cannot update the ref"), ref.buf);
+	transaction = ref_transaction_begin();
+	if (!transaction ||
+	    ref_transaction_update(transaction, ref.buf, object, prev,
+				   0, !is_null_sha1(prev)) ||
+	    ref_transaction_commit(transaction, NULL, &err))
+		die(_("%s: cannot update the ref: %s"), ref.buf, err.buf);
Makes sense for the _update and _commit case.  (BTW, why is have_old
a separate boolean instead of a bit in flags?)

For the _begin() case, can ref_transaction_begin() ever fail?  xcalloc
die()s on allocation failure.  So I think it's fine to assume
transaction is non-null (i.e., drop the !transaction condition), or if
you want to be defensive, then label it as a bug --- e.g.:

	if (!transaction)
		die("BUG: ref_transaction_begin() returned NULL?");

Otherwise if ref_transaction_begin regresses in the future and this
case is tripped then the message would be

	fatal: refs/tags/v1.0: cannot update the ref:

which is not as obvious an indicator that the user should contact
the mailing list.

Thanks,
Jonathan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help