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: 10+ 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 5:51 ` Patrick Steinhardt [this message]
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-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-20 7:53 ` Jeff King
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox