git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Couder <christian.couder@gmail.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org, jltobler@gmail.com, ps@pks.im,
	gitster@pobox.com,  sunshine@sunshineco.com,
	Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH v3 2/2] receive-pack: handle reference deletions separately
Date: Thu, 12 Jun 2025 19:03:00 +0200	[thread overview]
Message-ID: <CAP8UFD0Az9YUd7tHbCWjrZ5bTv1V_0RZ2azasPmOrpf+ARMjug@mail.gmail.com> (raw)
In-Reply-To: <20250606-6769-address-test-failures-in-the-next-branch-caused-by-batched-reference-updates-v3-2-e1c41693bd35@gmail.com>

On Fri, Jun 6, 2025 at 10:41 AM Karthik Nayak <karthik.188@gmail.com> wrote:
>
> In 9d2962a7c4 (receive-pack: use batched reference updates, 2025-05-19)
> we updated the 'git-receive-pack(1)' command to use batched reference
> updates. One edge case which was missed during this implementation was
> when a user pushes multiple branches such as:
>
>   delete refs/heads/branch/conflict
>   create refs/heads/branch
>
> Before using batched updates, the references would be applied
> sequentially and hence no conflicts would arise. With batched updates,
> while the first update applies, the second fails due to F/D conflict.

Nit: it looks like "D/F conflict" is more often used than "F/D
conflict" in the Git code base:

$ git grep -i 'd/f conflict' | wc -l
119
$ git grep -i 'f/d conflict' | wc -l
7

> A
> similar issue was present in 'git-fetch(1)' and was fixed by using
> separating out reference pruning into a separate transaction. Apply a

Maybe: s/using separating out/separating out/

> similar mechanism for 'git-receive-pack(1)' and separate out reference
> deletions into its own batch.
>
> This means 'git-receive-pack(1)' will now use upto two transactions,
> whereas before using batched updates it would use _at least_ two
> transactions. So using batched updates is still the better option.
>
> Add a test to validate this behavior.
>
> Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
> ---
>  builtin/receive-pack.c | 100 ++++++++++++++++++++++++++++++++-----------------
>  t/t5516-fetch-push.sh  |  17 +++++++--
>  2 files changed, 79 insertions(+), 38 deletions(-)
>
> diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> index 9e3cfb85cf..8ee792d2f8 100644
> --- a/builtin/receive-pack.c
> +++ b/builtin/receive-pack.c
> @@ -1867,47 +1867,79 @@ static void execute_commands_non_atomic(struct command *commands,
>         const char *reported_error = NULL;
>         struct strmap failed_refs = STRMAP_INIT;
>
> -       transaction = ref_store_transaction_begin(get_main_ref_store(the_repository),
> -                                                 REF_TRANSACTION_ALLOW_FAILURE, &err);
> -       if (!transaction) {
> -               rp_error("%s", err.buf);
> -               strbuf_reset(&err);
> -               reported_error = "transaction failed to start";
> -               goto failure;
> -       }
> +       /*
> +        * Reference updates, where F/D conflicts shouldn't arise due to

Nit: here also maybe "D/F conflicts" is more standard.

> +        * one reference being deleted, while the other being created
> +        * are treated as conflicts in batched updates. This is because
> +        * we don't do conflict resolution inside a transaction. To
> +        * mitigate this, delete references in a separate batch.
> +        */
> +       enum processing_phase {
> +               PHASE_DELETIONS,
> +               PHASE_OTHERS
> +       };
>
> -       for (cmd = commands; cmd; cmd = cmd->next) {
> -               if (!should_process_cmd(cmd) || cmd->run_proc_receive)
> -                       continue;
> +       for (enum processing_phase phase = PHASE_DELETIONS; phase <= PHASE_OTHERS; phase++) {
> +               for (cmd = commands; cmd; cmd = cmd->next) {
> +                       if (!should_process_cmd(cmd) || cmd->run_proc_receive)
> +                               continue;
>
> -               cmd->error_string = update(cmd, si);
> -       }
> +                       if (phase == PHASE_DELETIONS && !is_null_oid(&cmd->new_oid))
> +                               continue;
> +                       else if (phase == PHASE_OTHERS && is_null_oid(&cmd->new_oid))
> +                               continue;
>
> -       if (ref_transaction_commit(transaction, &err)) {
> -               rp_error("%s", err.buf);
> -               reported_error = "failed to update refs";
> -               goto failure;
> -       }
> +                       /*
> +                        * Lazily create a transaction only when we know there are
> +                        * updates to be added.
> +                        */
> +                       if (!transaction) {
> +                               transaction = ref_store_transaction_begin(get_main_ref_store(the_repository),
> +                                                                         REF_TRANSACTION_ALLOW_FAILURE, &err);
> +                               if (!transaction) {
> +                                       rp_error("%s", err.buf);
> +                                       strbuf_reset(&err);
> +                                       reported_error = "transaction failed to s1tart";

s/s1tart/start/

> +                                       goto failure;
> +                               }
> +                       }
>
> -       ref_transaction_for_each_rejected_update(transaction,
> -                                                ref_transaction_rejection_handler,
> -                                                &failed_refs);
> +                       cmd->error_string = update(cmd, si);
> +               }
>
> -       if (strmap_empty(&failed_refs))
> -               goto cleanup;
> +               /*
> +                * If no transaction was created, there is nothing to commit.
> +                */

Nit: the comment needs a single line, so maybe:

              /* No transaction, so nothing to commit */

> +               if (!transaction)
> +                       goto cleanup;
>
> -failure:
> -       for (cmd = commands; cmd; cmd = cmd->next) {
> -               if (reported_error)
> -                       cmd->error_string = reported_error;
> -               else if (strmap_contains(&failed_refs, cmd->ref_name))
> -                       cmd->error_string = strmap_get(&failed_refs, cmd->ref_name);
> -       }
> +               if (ref_transaction_commit(transaction, &err)) {
> +                       rp_error("%s", err.buf);
> +                       reported_error = "failed to update refs";
> +                       goto failure;
> +               }
>
> -cleanup:
> -       ref_transaction_free(transaction);
> -       strmap_clear(&failed_refs, 0);
> -       strbuf_release(&err);
> +               ref_transaction_for_each_rejected_update(transaction,
> +                                                        ref_transaction_rejection_handler,
> +                                                        &failed_refs);
> +
> +               if (strmap_empty(&failed_refs))
> +                       goto cleanup;
> +
> +       failure:

This label looks indented while previously it was right at the start
of the line. Not sure if we have a standard for that, but a few quick
greps seems to show that goto labels are most often at the start of
the line.

> +               for (cmd = commands; cmd; cmd = cmd->next) {
> +                       if (reported_error)
> +                               cmd->error_string = reported_error;
> +                       else if (strmap_contains(&failed_refs, cmd->ref_name))
> +                               cmd->error_string = strmap_get(&failed_refs, cmd->ref_name);
> +               }
> +
> +       cleanup:

Idem for how this label is indented.

> +               ref_transaction_free(transaction);
> +               transaction = NULL;
> +               strmap_clear(&failed_refs, 0);
> +               strbuf_release(&err);
> +       }
>  }

  reply	other threads:[~2025-06-12 17:03 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-02  9:57 [PATCH 0/3] refs: fix some bugs with batched-updates Karthik Nayak
2025-06-02  9:57 ` [PATCH 1/3] refs/files: skip updates with errors in batched updates Karthik Nayak
2025-06-02 12:00   ` Patrick Steinhardt
2025-06-02 12:46     ` Karthik Nayak
2025-06-02 15:06       ` Junio C Hamano
2025-06-02 17:13         ` Karthik Nayak
2025-06-02  9:57 ` [PATCH 2/3] t5516: use double quotes for tests with variables Karthik Nayak
2025-06-02 16:59   ` Eric Sunshine
2025-06-02 17:13     ` Karthik Nayak
2025-06-02  9:57 ` [PATCH 3/3] receive-pack: handle reference deletions separately Karthik Nayak
2025-06-02 11:59   ` Patrick Steinhardt
2025-06-02 12:54     ` Karthik Nayak
2025-06-02 15:20     ` Junio C Hamano
2025-06-02 15:56       ` Patrick Steinhardt
2025-06-04 11:08         ` Karthik Nayak
2025-06-05  8:19 ` [PATCH v2 0/2] refs: fix some bugs with batched-updates Karthik Nayak
2025-06-05  8:19   ` [PATCH v2 1/2] refs/files: skip updates with errors in batched updates Karthik Nayak
2025-06-05  8:19   ` [PATCH v2 2/2] receive-pack: handle reference deletions separately Karthik Nayak
2025-06-05  8:47     ` Patrick Steinhardt
2025-06-05  9:08       ` Karthik Nayak
2025-06-06  8:41 ` [PATCH v3 0/2] refs: fix some bugs with batched-updates Karthik Nayak
2025-06-06  8:41   ` [PATCH v3 1/2] refs/files: skip updates with errors in batched updates Karthik Nayak
2025-06-06  8:41   ` [PATCH v3 2/2] receive-pack: handle reference deletions separately Karthik Nayak
2025-06-12 17:03     ` Christian Couder [this message]
2025-06-12 20:40       ` Junio C Hamano
2025-06-13  7:23       ` Karthik Nayak
2025-06-13  8:10 ` [PATCH v4 0/2] refs: fix some bugs with batched-updates Karthik Nayak
2025-06-13  8:10   ` [PATCH v4 1/2] refs/files: skip updates with errors in batched updates Karthik Nayak
2025-06-13  8:10   ` [PATCH v4 2/2] receive-pack: handle reference deletions separately Karthik Nayak
2025-06-13 15:46     ` Junio C Hamano
2025-06-19  9:39       ` Karthik Nayak
2025-06-13 12:43   ` [PATCH v4 0/2] refs: fix some bugs with batched-updates Christian Couder
2025-06-13 18:57     ` Junio C Hamano
2025-06-20  7:15 ` [PATCH v5 " Karthik Nayak
2025-06-20  7:15   ` [PATCH v5 1/2] refs/files: skip updates with errors in batched updates Karthik Nayak
2025-06-20  7:15   ` [PATCH v5 2/2] receive-pack: handle reference deletions separately Karthik Nayak
2025-06-20 16:21   ` [PATCH v5 0/2] refs: fix some bugs with batched-updates Junio C Hamano
2025-06-21 11:08     ` Karthik Nayak
2025-06-22  4:23       ` Junio C Hamano
2025-06-22 14:20         ` Karthik Nayak

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=CAP8UFD0Az9YUd7tHbCWjrZ5bTv1V_0RZ2azasPmOrpf+ARMjug@mail.gmail.com \
    --to=christian.couder@gmail.com \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jltobler@gmail.com \
    --cc=karthik.188@gmail.com \
    --cc=ps@pks.im \
    --cc=sunshine@sunshineco.com \
    /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).