Re: [PATCH 1/2] update-ref: Allow creation of multiple transactions
- From
Jeff King <peff@peff.net>
- Date
- Nov 5, 2020, 19:29 UTC
- Message-ID
- <20201105192901.GA121650@coredump.intra.peff.net>
- In-Reply-To
- <eec7c2e8ec3e49b34066190d59fc45276bed637f.1604501265.git.ps@pks.im>
On Wed, Nov 04, 2020 at 03:57:17PM +0100, Patrick Steinhardt wrote:
Show 9 quoted lines
> 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.
Show 11 quoted lines
> 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.
Show 19 quoted lines
> --- 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