From: Ronnie Sahlberg <sahlberg@google.com>
To: git@vger.kernel.org
Cc: mhagger@alum.mit.edu, Ronnie Sahlberg <sahlberg@google.com>
Subject: [PATCH 21/31] refs.c allow multiple updates of the same ref in a transaction
Date: Wed, 14 May 2014 15:13:20 -0700 [thread overview]
Message-ID: <1400105610-21194-22-git-send-email-sahlberg@google.com> (raw)
In-Reply-To: <1400105610-21194-1-git-send-email-sahlberg@google.com>
Allow multiple updates of a ref in the same transaction as long as
each update has have_old and old_sha1 matches the new_sha1 of the
previous update.
Add a test that verifies that a valid sequence such as
create ref a
update ref b a
update ref c b
works and a test that an invalid sequence such as this still fails:
update ref a c
update ref b b
update ref c c
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
---
refs.c | 23 +++++++++++++++++------
t/t1400-update-ref.sh | 23 +++++++++++++++++++++--
2 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/refs.c b/refs.c
index 76cab6e..87cdd91 100644
--- a/refs.c
+++ b/refs.c
@@ -3455,12 +3455,6 @@ int transaction_update_sha1(struct ref_transaction *transaction,
if (update->lock)
return 0;
- /* If we could not lock the ref it means we either collided with a
- different command or that we tried to perform a second update to
- the same ref from within the same transaction.
- */
- transaction->status = REF_TRANSACTION_ERROR;
-
/* -1 is the update we just added. Start at -2 and find the most recent
previous update for this ref.
*/
@@ -3472,6 +3466,23 @@ int transaction_update_sha1(struct ref_transaction *transaction,
update->refname))
break;
}
+ /* If the current update has_old==1 and old_sha1 matches the new_sha1
+ * of the previous update then merge the two updates into one.
+ */
+ if (i >= 0 && update->have_old && !hashcmp(update->old_sha1,
+ transaction->updates[i]->new_sha1)) {
+ hashcpy(transaction->updates[i]->new_sha1, update->new_sha1);
+ transaction->nr--;
+ free((char *)transaction->updates[transaction->nr]->msg);
+ free(transaction->updates[transaction->nr]);
+ return 0;
+ }
+ /* If we could not lock the ref it means we either collided with a
+ different command or that we tried to perform a second update to
+ the same ref from within the same transaction.
+ */
+ transaction->status = REF_TRANSACTION_ERROR;
+
if (err)
if (i >= 0) {
const char *str =
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index f9b7bef..078cd4b 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -446,7 +446,7 @@ test_expect_success 'stdin fails option with unknown name' '
grep "fatal: option unknown: unknown" err
'
-test_expect_success 'stdin fails with duplicate refs' '
+test_expect_success 'stdin fails with duplicate create refs' '
cat >stdin <<-EOF &&
create $a $m
create $b $m
@@ -464,6 +464,25 @@ test_expect_success 'stdin create ref works' '
test_cmp expect actual
'
+test_expect_success 'stdin succeeds with correctly chained update refs' '
+ cat >stdin <<-EOF &&
+ update $a $A $m
+ update $a $B $A
+ update $a $C $B
+ EOF
+ git update-ref --stdin <stdin
+'
+
+test_expect_success 'stdin fails with incorrectly chained update refs' '
+ cat >stdin <<-EOF &&
+ update $a $A $C
+ update $a $B $B
+ update $a $B $B
+ EOF
+ test_must_fail git update-ref --stdin <stdin &&
+ grep "fatal: Multiple updates for ref '"'"'$a'"'"' not allowed." err
+'
+
test_expect_success 'stdin succeeds with quoted argument' '
git update-ref -d $a &&
echo "create $a \"$m\"" >stdin &&
@@ -786,7 +805,7 @@ test_expect_success 'stdin -z fails option with unknown name' '
grep "fatal: option unknown: unknown" err
'
-test_expect_success 'stdin -z fails with duplicate refs' '
+test_expect_success 'stdin -z fails with duplicate create refs' '
printf $F "create $a" "$m" "create $b" "$m" "create $a" "$m" >stdin &&
test_must_fail git update-ref -z --stdin <stdin 2>err &&
grep "fatal: Multiple updates for ref '"'"'$a'"'"' not allowed." err
--
2.0.0.rc3.506.g3739a35
next prev parent reply other threads:[~2014-05-14 22:14 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 22:12 [PATCH 00/31] Finish implementing ref and reflog transactions Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 01/31] refs.c make ref_transaction_create a wrapper to ref_transaction_update Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 02/31] refs.c: make ref_transaction_delete a wrapper for ref_transaction_update Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 03/31] refs.c: rename the transaction functions Ronnie Sahlberg
2014-05-16 21:15 ` Junio C Hamano
2014-05-19 23:11 ` Ronnie Sahlberg
2014-05-19 23:25 ` Junio C Hamano
2014-05-14 22:13 ` [PATCH 04/31] refs.c: add a new update_type field to ref_update Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 05/31] refs.c: add a function to append a reflog entry to a fd Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 06/31] refs.c: add a transaction function to append a reflog entry Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 07/31] refs.c: add a flag to allow reflog updates to truncate the log Ronnie Sahlberg
2014-05-16 21:20 ` Junio C Hamano
2014-05-19 23:27 ` Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 08/31] refs.c: only write reflog update if msg is non-NULL Ronnie Sahlberg
2014-05-16 21:24 ` Junio C Hamano
2014-05-19 22:55 ` Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 09/31] refs.c: allow multiple reflog updates during a single transaction Ronnie Sahlberg
2014-05-16 21:35 ` Junio C Hamano
2014-05-16 22:01 ` Eric Sunshine
2014-05-19 22:58 ` Ronnie Sahlberg
2014-05-19 23:06 ` Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 10/31] reflog.c: use a reflog transaction when writing during expire Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 11/31] refs.c: null terminate the string in copy_msg Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 12/31] refs.c: track the refnames we are deleting in the transaction structure Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 13/31] refs.c: update the list of deleted refs during _update instead of _commit Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 14/31] refs.c: return error instead of dying when locking fails during transaction Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 15/31] refs.c: lock the ref during _update instead of during _commit Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 16/31] refs.c: add an error argument to create/delete/update just like commit Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 17/31] refs.c: make _update_reflog take an error argument Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 18/31] refs.c: return immediately from _commit if the transaction has an error Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 19/31] tests: move tests for -z update/delete/verify to after the ref is created Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 20/31] refs.c: check for lock conflicts already in _update Ronnie Sahlberg
2014-05-14 22:13 ` Ronnie Sahlberg [this message]
2014-05-14 22:13 ` [PATCH 22/31] refs.c: release all remaining locks during transaction_free Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 23/31] reflog.c: use the existing transaction to also lock and update the ref Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 24/31] refs.c: make unlock_ref static Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 25/31] refs.c: make close_ref static Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 26/31] refs.c: make commit_ref static Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 27/31] refs.c: remove the function lock_any_ref_for_update Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 28/31] refs.c: make struct ref_lock private to refs.c Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 29/31] refs.c: allow passing raw git_committer_info as email to _update_reflog Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 30/31] refs.c: move ref_update and other definitions to earlier in the file Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 31/31] refs.c: use the transaction to manage the reflog in rename_refs Ronnie Sahlberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1400105610-21194-22-git-send-email-sahlberg@google.com \
--to=sahlberg@google.com \
--cc=git@vger.kernel.org \
--cc=mhagger@alum.mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).