From: Patrick Steinhardt <ps@pks.im>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/3] reftable/stack: remove `REFTABLE_STACK_NEW_ADDITION_RELOAD`
Date: Thu, 20 Aug 2026 07:51:16 +0200 [thread overview]
Message-ID: <aoaV1GBPWwvTsYRm@pks.im> (raw)
In-Reply-To: <20260819-740-optimize-reloading-the-reftable-stack-v1-1-6bf5305d4e43@gmail.com>
On Wed, Aug 19, 2026 at 03:19:37PM +0200, Karthik Nayak wrote:
> In 80e7342ea8 (reftable/stack: allow locking of outdated stacks,
> 2024-09-24), the `REFTABLE_STACK_NEW_ADDITION_RELOAD` was introduced so
> that callers of `reftable_stack_init_addition()` can also reload the
> stack if there was a concurrent update made before the lock was
> obtained.
>
> Then 16684b6fae (refs/reftable: always reload stacks when creating
> lock, 2025-08-12) updated all of the remaining call-sites to propagate
> this flag to ensure that we always reload the stack whenever there was a
> concurrent update.
>
> As all calls to `reftable_stack_init_addition()` inevitably propagate
> the flag, it is safe to remove the flag and its associated code and make
> the reloading of the stack the default flow. This makes it easier to
> follow the flow and simplifies the logic.
>
> The only exceptions are:
>
> 1. Unit tests, where we explicitly do not propagate the flag. These
> tests are now modified with the new status quo.
>
> 2. `reftable_stack_clean_locked()`, which was propagating 0 to
> `reftable_stack_new_addition()` but was then manually reloading the
> stack after. Here the new flow will achieve the same, while also
> allowing us to remove the manual reload.
libgit2 uses this flag though, so we'd have to adapt it, too. As far as
I can see though all of the calls to `reftable_stack_add()` it has pass
this flag.
> diff --git a/reftable/reftable-stack.h b/reftable/reftable-stack.h
> index 5d22d84e80..5d224f8079 100644
> --- a/reftable/reftable-stack.h
> +++ b/reftable/reftable-stack.h
> @@ -58,22 +58,13 @@ uint64_t reftable_stack_next_update_index(struct reftable_stack *st);
> /* holds a transaction to add tables at the top of a stack. */
> struct reftable_addition;
>
> -enum {
> - /*
> - * Reload the stack when the stack is out-of-date after locking it.
> - */
> - REFTABLE_STACK_NEW_ADDITION_RELOAD = (1 << 0),
> -};
> -
> /*
> * returns a new transaction to add reftables to the given stack. As a side
> - * effect, the ref database is locked. Accepts REFTABLE_STACK_NEW_ADDITION_*
> - * flags.
> + * effect, the ref database is locked.
> */
> int reftable_stack_new_addition(struct reftable_addition **dest,
> struct reftable_stack *st,
> - const struct reftable_write_options *opts,
> - unsigned int flags);
> + const struct reftable_write_options *opts);
>
> /* Adds a reftable to transaction. */
> int reftable_addition_add(struct reftable_addition *add,
We're already busy adapting this function anyway, so do we maybe want to
fix its name to `reftable_stack_addition_new` while at it?
Patrick
next prev parent reply other threads:[~2026-08-20 5:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-19 13:19 [PATCH 0/3] reftable/stack: avoid reloading the stack when locked Karthik Nayak
2026-08-19 13:19 ` [PATCH 1/3] reftable/stack: remove `REFTABLE_STACK_NEW_ADDITION_RELOAD` Karthik Nayak
2026-08-19 16:28 ` Justin Tobler
2026-08-20 21:15 ` Karthik Nayak
2026-08-20 5:51 ` Patrick Steinhardt [this message]
2026-08-20 21:20 ` Karthik Nayak
2026-08-20 21:23 ` Karthik Nayak
2026-08-19 13:19 ` [PATCH 2/3] reftable/stack: move list lock to `struct reftable_stack` Karthik Nayak
2026-08-19 16:39 ` Justin Tobler
2026-08-19 17:17 ` Junio C Hamano
2026-08-23 15:28 ` Karthik Nayak
2026-08-19 13:19 ` [PATCH 3/3] reftable/stack: avoid reloading the stack when already locked Karthik Nayak
2026-08-19 16:49 ` Justin Tobler
2026-08-23 15:39 ` Karthik Nayak
2026-08-20 7:53 ` Jeff King
2026-08-23 17:39 ` Karthik Nayak
2026-08-24 4:59 ` Jeff King
2026-08-24 9:30 ` [PATCH v2 0/4] reftable/stack: avoid reloading the stack when locked Karthik Nayak
2026-08-24 9:30 ` [PATCH v2 1/4] reftable/stack: remove `REFTABLE_STACK_NEW_ADDITION_RELOAD` Karthik Nayak
2026-08-24 9:31 ` [PATCH v2 2/4] reftable/stack: rename reftable_stack_new_addition() Karthik Nayak
2026-08-24 9:31 ` [PATCH v2 3/4] reftable/stack: move list lock to `struct reftable_stack` Karthik Nayak
2026-08-24 9:31 ` [PATCH v2 4/4] reftable/stack: avoid reloading the stack when already locked 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=aoaV1GBPWwvTsYRm@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=karthik.188@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.