Re: [PATCH 1/2] update-ref: Allow creation of multiple transactions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 04, 2020 at 03:57:17PM +0100, Patrick Steinhardt wrote:

> While git-update-ref has recently grown commands which allow interactive
> control of transactions in e48cf33b61 (update-ref: implement interactive
> transaction handling, 2020-04-02), it is not yet possible to create
> multiple transactions in a single session. To do so, one currently still
> needs to invoke the executable multiple times.
> 
> This commit addresses this shortcoming by allowing the "start" command
> to create a new transaction if the current transaction has already been
> either committed or aborted.

Thanks for working on this. The amount of change needed is indeed quite
pleasant.

> diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
> index d401234b03..48b6683071 100644
> --- a/Documentation/git-update-ref.txt
> +++ b/Documentation/git-update-ref.txt
> @@ -125,7 +125,8 @@ option::
>  start::
>  	Start a transaction. In contrast to a non-transactional session, a
>  	transaction will automatically abort if the session ends without an
> -	explicit commit.
> +	explicit commit. This command may create a new empty transaction when
> +	the current one has been committed or aborted already.

Reading this made me wonder what would happen if we send a "start" when
the current one _hasn't_ been committed or aborted. I.e., what does:

  git update-ref --stdin <<EOF
  start
  create refs/heads/foo ...
  start
  commit
  EOF

do? It turns out that the second start is ignored totally (and the
commit does indeed update foo). I wonder if we ought to complain about
it. But that is completely orthogonal to your patch. The behavior is the
same before and after.

> --- a/builtin/update-ref.c
> +++ b/builtin/update-ref.c
> @@ -446,7 +446,18 @@ static void update_refs_stdin(void)
>  			state = cmd->state;
>  			break;
>  		case UPDATE_REFS_CLOSED:
> -			die("transaction is closed");
> +			if (cmd->state != UPDATE_REFS_STARTED)
> +				die("transaction is closed");
> +
> +			/*
> +			 * Open a new transaction if we're currently closed and
> +			 * get a "start".
> +			 */
> +			state = cmd->state;
> +			transaction = ref_transaction_begin(&err);
> +			if (!transaction)
> +				die("%s", err.buf);
> +

Very nice. This duplicates the state and transaction setup at the start
of the function, which made me wonder if we could do this:

diff --git a/builtin/update-ref.c b/builtin/update-ref.c
index bb65129012..140f0d30e9 100644
--- a/builtin/update-ref.c
+++ b/builtin/update-ref.c
@@ -385,14 +385,10 @@ static const struct parse_cmd {
 static void update_refs_stdin(void)
 {
 	struct strbuf input = STRBUF_INIT, err = STRBUF_INIT;
-	enum update_refs_state state = UPDATE_REFS_OPEN;
+	enum update_refs_state state = UPDATE_REFS_CLOSED;
 	struct ref_transaction *transaction;
 	int i, j;
 
-	transaction = ref_transaction_begin(&err);
-	if (!transaction)
-		die("%s", err.buf);
-
 	/* Read each line dispatch its command */
 	while (!strbuf_getwholeline(&input, stdin, line_termination)) {
 		const struct parse_cmd *cmd = NULL;

and just have it auto-open. But of course that doesn't work because we
might not see an "open" command at all. Traditional callers will start
with create/update/etc, and our "auto-open" would complain.

> +test_expect_success 'transaction can create and delete' '
> +	cat >stdin <<-EOF &&
> +	start
> +	create refs/heads/create-and-delete $A
> +	commit
> +	start
> +	delete refs/heads/create-and-delete $A
> +	commit
> +	EOF
> +	git update-ref --stdin <stdin >actual &&
> +	printf "%s: ok\n" start commit start commit >expect &&
> +	test_path_is_missing .git/refs/heads/create-and-delete
> +'

The tests all look quite reasonable to me. Touching .git/refs like this
is a bit gross (and something we may have to deal with if we introduce
reftables, etc). But it's pretty pervasive in this file, so matching
the existing style is the best option for now.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux