From: Tian Yuchen <cat@malon.dev>
To: git@vger.kernel.org
Cc: gitster@pobox.com, Tian Yuchen <cat@malon.dev>
Subject: [PATCH v2] patch-ids: document intentional const-casting in patch_id_neq()
Date: Sun, 8 Mar 2026 23:02:03 +0800 [thread overview]
Message-ID: <20260308150203.86299-1-cat@malon.dev> (raw)
In-Reply-To: <20260308043131.77782-1-a3205153416@gmail.com>
The hashmap API requires the comparison function to take const pointers.
However, patch_id_neq() uses lazy evaluation to compute patch IDs on
demand.
Pre-calculating all patch IDs to achieve true const correctness would
introduce an unacceptable performance penalty.
Remove the eight-year-old "NEEDSWORK" comment and formally document
this intentional design trade-off.
Signed-off-by: Tian Yuchen <cat@malon.dev>
---
patch-ids.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/patch-ids.c b/patch-ids.c
index a5683b462c..35e6a974f1 100644
--- a/patch-ids.c
+++ b/patch-ids.c
@@ -41,7 +41,15 @@ static int patch_id_neq(const void *cmpfn_data,
const struct hashmap_entry *entry_or_key,
const void *keydata UNUSED)
{
- /* NEEDSWORK: const correctness? */
+ /*
+ * We drop the 'const' modifier here intentionally.
+ *
+ * The hashmap API requires us to treat the entries as const.
+ * However, to avoid performance regression, we lazily compute
+ * the patch IDs inside this comparison function. This fundamentally
+ * requires us to mutate the 'struct patch_id'. Therefore, we use
+ * container_of() to cast away the constness from the hashmap_entry.
+ */
struct diff_options *opt = (void *)cmpfn_data;
struct patch_id *a, *b;
--
2.43.0
next prev parent reply other threads:[~2026-03-08 15:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-08 4:31 [PATCH] patch-ids: achieve const correctness in patch_id_neq() Tian Yuchen
2026-03-08 6:26 ` Junio C Hamano
2026-03-08 14:42 ` Tian Yuchen
2026-03-08 15:02 ` Tian Yuchen [this message]
2026-03-09 0:26 ` [PATCH v2] patch-ids: document intentional const-casting " Junio C Hamano
2026-03-09 6:39 ` cat
2026-03-09 6:51 ` [PATCH v3] " Tian Yuchen
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=20260308150203.86299-1-cat@malon.dev \
--to=cat@malon.dev \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.