From: Patrick Steinhardt <ps@pks•im>
To: Karthik Nayak <karthik.188@gmail•com>
Cc: git@vger•kernel.org, David Bohman <debohman@gmail•com>,
jltobler@gmail•com, gitster@pobox•com
Subject: Re: [PATCH v4 2/2] fetch: fix non-conflicting tags not being committed
Date: Wed, 12 Nov 2025 07:16:52 +0100 [thread overview]
Message-ID: <aRQmVPe1RsFcr4hz@pks.im> (raw)
In-Reply-To: <20251111-fix-tags-not-fetching-v4-2-185d836ec62a@gmail.com>
On Tue, Nov 11, 2025 at 02:27:08PM +0100, Karthik Nayak wrote:
> The cleanup section is reached with `retcode` set in several scenarios:
>
> - `truncate_fetch_head()` and `open_fetch_head()` both set `retcode`
> before the transaction is created, so no commit is attempted.
>
> - `prune_refs()` sets `retcode` after creating the transaction, so
> the commit will now proceed. Before batched updates, `prune_refs()`
> created its own transaction internally with all-or-nothing
> semantics. This was done since all deletions were made without an
> old OID, which meant they were assumed to never fail. This change
> allows partial deletions to succeed, consistent with how other
> reference updates behave during fetch.
Okay, so we do have a change in behaviour for `prune_refs()`. I guess
the reasoning is sound, but I was wondering why we don't have a test for
this.
I guess the reason is that, as you said, it should in theory always
succeed. But what if with the "files" backend one of the refs that we're
about to prune was locked? Would that be a case where we continue with
pruning the remaining refs now?
Thanks!
Patrick
next prev parent reply other threads:[~2025-11-12 6:17 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-03 13:49 [PATCH] fetch: fix non-conflicting tags not being committed Karthik Nayak
2025-11-03 17:53 ` Eric Sunshine
2025-11-03 21:22 ` Karthik Nayak
2025-11-03 20:52 ` Justin Tobler
2025-11-06 8:39 ` [PATCH v2] " Karthik Nayak
2025-11-06 11:50 ` Patrick Steinhardt
2025-11-06 18:56 ` Junio C Hamano
2025-11-07 13:15 ` Karthik Nayak
2025-11-07 14:07 ` Patrick Steinhardt
2025-11-07 15:13 ` Karthik Nayak
2025-11-06 22:10 ` Justin Tobler
2025-11-07 14:01 ` Karthik Nayak
2025-11-08 21:34 ` [PATCH v3 0/2] " Karthik Nayak
2025-11-08 21:34 ` [PATCH v3 1/2] fetch: extract out reference committing logic Karthik Nayak
2025-11-10 7:34 ` Patrick Steinhardt
2025-11-10 13:11 ` Karthik Nayak
2025-11-08 21:34 ` [PATCH v3 2/2] fetch: fix non-conflicting tags not being committed Karthik Nayak
2025-11-10 7:34 ` Patrick Steinhardt
2025-11-10 13:23 ` Karthik Nayak
2025-11-11 13:27 ` [PATCH v4 0/2] " Karthik Nayak
2025-11-11 13:27 ` [PATCH v4 1/2] fetch: extract out reference committing logic Karthik Nayak
2025-11-11 13:27 ` [PATCH v4 2/2] fetch: fix non-conflicting tags not being committed Karthik Nayak
2025-11-12 6:16 ` Patrick Steinhardt [this message]
2025-11-12 8:52 ` Karthik Nayak
2025-11-12 16:34 ` Junio C Hamano
2025-11-13 13:38 ` [PATCH v5 0/2] " Karthik Nayak
2025-11-13 13:38 ` [PATCH v5 1/2] fetch: extract out reference committing logic Karthik Nayak
2025-11-13 13:38 ` [PATCH v5 2/2] fetch: fix non-conflicting tags not being committed Karthik Nayak
2025-11-13 21:23 ` Junio C Hamano
2025-11-15 22:16 ` Karthik Nayak
2025-11-17 0:02 ` Junio C Hamano
2025-11-17 15:38 ` Karthik Nayak
2025-11-18 11:27 ` [PATCH v6 0/3] " Karthik Nayak
2025-11-18 11:27 ` [PATCH v6 1/3] fetch: extract out reference committing logic Karthik Nayak
2025-11-18 11:27 ` [PATCH v6 2/3] fetch: fix non-conflicting tags not being committed Karthik Nayak
2025-11-18 11:27 ` [PATCH v6 3/3] fetch: fix failed batched updates skipping operations Karthik Nayak
2025-11-18 18:03 ` Junio C Hamano
2025-11-19 8:59 ` Karthik Nayak
2025-11-19 21:46 ` [PATCH v7 0/3] fetch: fix non-conflicting tags not being committed Karthik Nayak
2025-11-19 21:46 ` [PATCH v7 1/3] fetch: extract out reference committing logic Karthik Nayak
2025-11-19 21:46 ` [PATCH v7 2/3] fetch: fix non-conflicting tags not being committed Karthik Nayak
2025-11-19 21:46 ` [PATCH v7 3/3] fetch: fix failed batched updates skipping operations Karthik Nayak
2025-11-19 22:20 ` Eric Sunshine
2025-11-19 23:08 ` Junio C Hamano
2025-11-21 11:00 ` Karthik Nayak
2025-11-21 11:13 ` [PATCH v8 0/3] fetch: fix non-conflicting tags not being committed Karthik Nayak
2025-11-21 11:13 ` [PATCH v8 1/3] fetch: extract out reference committing logic Karthik Nayak
2025-11-21 11:13 ` [PATCH v8 2/3] fetch: fix non-conflicting tags not being committed Karthik Nayak
2025-12-01 12:58 ` Patrick Steinhardt
2025-12-02 22:26 ` Karthik Nayak
2025-11-21 11:13 ` [PATCH v8 3/3] fetch: fix failed batched updates skipping operations Karthik Nayak
2025-12-01 12:58 ` Patrick Steinhardt
2025-12-02 22:35 ` Karthik Nayak
2025-11-21 19:58 ` [PATCH v8 0/3] fetch: fix non-conflicting tags not being committed Junio C Hamano
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=aRQmVPe1RsFcr4hz@pks.im \
--to=ps@pks$(echo .)im \
--cc=debohman@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=jltobler@gmail$(echo .)com \
--cc=karthik.188@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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