From: Jeff King <peff@peff.net>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, Taylor Blau <me@ttaylorr.com>
Subject: Re: [PATCH 3/3] bisect: fix misuse of `refs_for_each_ref_in()`
Date: Thu, 29 Jan 2026 03:14:20 -0500 [thread overview]
Message-ID: <20260129081420.GA589284@coredump.intra.peff.net> (raw)
In-Reply-To: <20260128-b4-pks-fix-for-each-ref-in-misuse-v1-3-deccae3ea725@pks.im>
On Wed, Jan 28, 2026 at 09:49:22AM +0100, Patrick Steinhardt wrote:
> Furthermore, taking a closer look, we strip the prefix only to re-add it
> in `mark_for_removal()`. This is somewhat roundabout, as we can instead
> call `refs_for_each_fullref_in()` to not do any stripping at all. Do so
> to simplify the code a bit.
Yeah, I think the result is much better.
We might also want this simplification on top:
-- >8 --
Subject: [PATCH] bisect: simplify string_list memory handling
We declare the refs_for_removal string_list as NODUP, forcing us to
manually allocate strings we insert. And then when it comes time to
clean up, we set strdup_strings so that string_list_clear() will free
them for us.
This is a confusing pattern, and can be done much more simply by just
declaring the list with the DUP initializer in the first place.
It was written this way originally because one of the callsites
generated the item using xstrfmt(). But that spot switched to a plain
xstrdup() in cf01f617b9 (bisect: fix misuse of `refs_for_each_ref_in()`,
2026-01-28). That means we can now just let the string_list code handle
allocation itself.
Signed-off-by: Jeff King <peff@peff.net>
---
Even before cf01f617b9 we could have done:
string_list_append_nodup(&refs, xstrfmt(...));
to get a similar simplification, but after that commit it is even
easier.
bisect.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/bisect.c b/bisect.c
index 2cd97bc9fe..6b9e9d81c3 100644
--- a/bisect.c
+++ b/bisect.c
@@ -1183,8 +1183,7 @@ int estimate_bisect_steps(int all)
static int mark_for_removal(const struct reference *ref, void *cb_data)
{
struct string_list *refs = cb_data;
- char *bisect_ref = xstrdup(ref->name);
- string_list_append(refs, bisect_ref);
+ string_list_append(refs, ref->name);
return 0;
}
@@ -1193,16 +1192,15 @@ int bisect_clean_state(void)
int result = 0;
/* There may be some refs packed during bisection */
- struct string_list refs_for_removal = STRING_LIST_INIT_NODUP;
+ struct string_list refs_for_removal = STRING_LIST_INIT_DUP;
refs_for_each_fullref_in(get_main_ref_store(the_repository),
"refs/bisect/", NULL, mark_for_removal,
&refs_for_removal);
- string_list_append(&refs_for_removal, xstrdup("BISECT_HEAD"));
- string_list_append(&refs_for_removal, xstrdup("BISECT_EXPECTED_REV"));
+ string_list_append(&refs_for_removal, "BISECT_HEAD");
+ string_list_append(&refs_for_removal, "BISECT_EXPECTED_REV");
result = refs_delete_refs(get_main_ref_store(the_repository),
"bisect: remove", &refs_for_removal,
REF_NO_DEREF);
- refs_for_removal.strdup_strings = 1;
string_list_clear(&refs_for_removal, 0);
unlink_or_warn(git_path_bisect_ancestors_ok());
unlink_or_warn(git_path_bisect_log());
--
2.53.0.rc2.296.g6748ed0491
next prev parent reply other threads:[~2026-01-29 8:14 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-28 8:49 [PATCH 0/3] Fix misuse of `refs_for_each_ref_in()` Patrick Steinhardt
2026-01-28 8:49 ` [PATCH 1/3] pack-bitmap: deduplicate logic to iterate over preferred bitmap tips Patrick Steinhardt
2026-01-28 10:37 ` Karthik Nayak
2026-01-29 2:16 ` Taylor Blau
2026-01-29 16:35 ` Junio C Hamano
2026-01-30 12:58 ` Patrick Steinhardt
2026-01-28 8:49 ` [PATCH 2/3] pack-bitmap: fix bug with exact ref match in "pack.preferBitmapTips" Patrick Steinhardt
2026-01-28 11:04 ` Karthik Nayak
2026-01-29 2:31 ` Taylor Blau
2026-01-29 16:52 ` Junio C Hamano
2026-01-29 19:34 ` Taylor Blau
2026-01-29 23:17 ` Junio C Hamano
2026-01-30 12:58 ` Patrick Steinhardt
2026-01-28 8:49 ` [PATCH 3/3] bisect: fix misuse of `refs_for_each_ref_in()` Patrick Steinhardt
2026-01-29 8:14 ` Jeff King [this message]
2026-01-29 17:28 ` Junio C Hamano
2026-01-30 12:58 ` Patrick Steinhardt
2026-01-28 11:05 ` [PATCH 0/3] Fix " Karthik Nayak
2026-01-30 13:27 ` [PATCH v2 0/4] " Patrick Steinhardt
2026-01-30 13:27 ` [PATCH v2 1/4] pack-bitmap: deduplicate logic to iterate over preferred bitmap tips Patrick Steinhardt
2026-01-30 13:27 ` [PATCH v2 2/4] pack-bitmap: fix bug with exact ref match in "pack.preferBitmapTips" Patrick Steinhardt
2026-02-02 2:13 ` Taylor Blau
2026-02-06 7:13 ` Patrick Steinhardt
2026-01-30 13:27 ` [PATCH v2 3/4] bisect: fix misuse of `refs_for_each_ref_in()` Patrick Steinhardt
2026-01-30 13:27 ` [PATCH v2 4/4] bisect: simplify string_list memory handling Patrick Steinhardt
2026-01-30 16:56 ` Junio C Hamano
2026-02-02 2:14 ` Taylor Blau
2026-02-06 7:49 ` [PATCH v3 0/4] Fix misuse of `refs_for_each_ref_in()` Patrick Steinhardt
2026-02-06 7:49 ` [PATCH v3 1/4] pack-bitmap: deduplicate logic to iterate over preferred bitmap tips Patrick Steinhardt
2026-02-06 7:49 ` [PATCH v3 2/4] pack-bitmap: fix bug with exact ref match in "pack.preferBitmapTips" Patrick Steinhardt
2026-02-06 17:18 ` Junio C Hamano
2026-02-06 7:49 ` [PATCH v3 3/4] bisect: fix misuse of `refs_for_each_ref_in()` Patrick Steinhardt
2026-02-06 7:49 ` [PATCH v3 4/4] bisect: simplify string_list memory handling Patrick Steinhardt
2026-02-18 18:36 ` [PATCH v3 0/4] Fix misuse of `refs_for_each_ref_in()` Taylor Blau
2026-02-19 15:22 ` Junio C Hamano
2026-02-19 7:57 ` [PATCH v4 " Patrick Steinhardt
2026-02-19 7:57 ` [PATCH v4 1/4] pack-bitmap: deduplicate logic to iterate over preferred bitmap tips Patrick Steinhardt
2026-02-19 7:57 ` [PATCH v4 2/4] pack-bitmap: fix bug with exact ref match in "pack.preferBitmapTips" Patrick Steinhardt
2026-02-19 7:57 ` [PATCH v4 3/4] bisect: fix misuse of `refs_for_each_ref_in()` Patrick Steinhardt
2026-02-19 7:57 ` [PATCH v4 4/4] bisect: simplify string_list memory handling Patrick Steinhardt
2026-02-26 17:39 ` [PATCH v4 0/4] Fix misuse of `refs_for_each_ref_in()` Junio C Hamano
2026-02-26 17:39 ` 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=20260129081420.GA589284@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
--cc=ps@pks.im \
/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