From: Patrick Steinhardt <ps@pks.im>
To: Kristofer Karlsson via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Kristofer Karlsson <krka@spotify.com>
Subject: Re: [PATCH v2 2/2] reftable: fix quadratic behavior in the presence of tombstones
Date: Thu, 9 Jul 2026 15:53:44 +0200 [thread overview]
Message-ID: <ak-n6K4heV2kHviZ@pks.im> (raw)
In-Reply-To: <c13f15ddc20f721443fa1d462ea1b7c2356fbffc.1783598912.git.gitgitgadget@gmail.com>
On Thu, Jul 09, 2026 at 12:08:31PM +0000, Kristofer Karlsson via GitGitGadget wrote:
> diff --git a/reftable/stack.c b/reftable/stack.c
> index ab12926708..fd7d8f3f1e 100644
> --- a/reftable/stack.c
> +++ b/reftable/stack.c
> @@ -337,7 +337,6 @@ static int reftable_stack_reload_once(struct reftable_stack *st,
> /* Update the stack to point to the new tables. */
> if (st->merged)
> reftable_merged_table_free(st->merged);
> - new_merged->suppress_deletions = 1;
> st->merged = new_merged;
>
> if (st->tables)
Okay, we still retain the field after this patch. But the question is:
how would libgit2 now set it? I think we should rather extend the
`struct reftable_stack_options` so that the caller can control whether
or not to suppress deletions at stack creation time.
Thanks!
Patrick
next prev parent reply other threads:[~2026-07-09 13:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 13:35 [PATCH 0/2] reftable: fix quadratic behavior when re-creating deleted refs Kristofer Karlsson via GitGitGadget
2026-07-06 13:35 ` [PATCH 1/2] t: add tests for ref tombstone scenarios Kristofer Karlsson via GitGitGadget
2026-07-07 15:24 ` Patrick Steinhardt
2026-07-07 16:12 ` Kristofer Karlsson
2026-07-08 5:59 ` Patrick Steinhardt
2026-07-08 7:28 ` Kristofer Karlsson
2026-07-06 13:35 ` [PATCH 2/2] reftable: fix quadratic behavior when re-creating deleted refs Kristofer Karlsson via GitGitGadget
2026-07-07 15:24 ` Patrick Steinhardt
2026-07-07 16:04 ` Kristofer Karlsson
2026-07-08 11:15 ` [PATCH 0/2] " brian m. carlson
2026-07-09 12:08 ` [PATCH v2 " Kristofer Karlsson via GitGitGadget
2026-07-09 12:08 ` [PATCH v2 1/2] t/perf: add perf test for ref tombstone scenarios Kristofer Karlsson via GitGitGadget
2026-07-09 12:08 ` [PATCH v2 2/2] reftable: fix quadratic behavior in the presence of tombstones Kristofer Karlsson via GitGitGadget
2026-07-09 13:53 ` Patrick Steinhardt [this message]
2026-07-09 14:48 ` Kristofer Karlsson
2026-07-09 14:54 ` Patrick Steinhardt
2026-07-10 10:36 ` [PATCH v3 0/2] reftable: fix quadratic behavior when re-creating deleted refs Kristofer Karlsson via GitGitGadget
2026-07-10 10:36 ` [PATCH v3 1/2] t/perf: add perf test for ref tombstone scenarios Kristofer Karlsson via GitGitGadget
2026-07-10 10:36 ` [PATCH v3 2/2] reftable: fix quadratic behavior in the presence of tombstones Kristofer Karlsson via GitGitGadget
2026-07-10 14:32 ` Patrick Steinhardt
2026-07-10 15:03 ` Kristofer Karlsson
2026-07-13 5:14 ` Patrick Steinhardt
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=ak-n6K4heV2kHviZ@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=krka@spotify.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