From: Tian Yuchen <cat@malon.dev>
To: git@vger.kernel.org
Cc: gitster@pobox.com, Tian Yuchen <cat@malon.dev>
Subject: [PATCH v3] patch-ids: document intentional const-casting in patch_id_neq()
Date: Mon, 9 Mar 2026 14:51:40 +0800 [thread overview]
Message-ID: <20260309065140.108644-1-cat@malon.dev> (raw)
In-Reply-To: <20260308150203.86299-1-cat@malon.dev>
The hashmap API requires the comparison function to take const pointers.
However, patch_id_neq() uses lazy evaluation to compute patch IDs on
demand. As established in b3dfeebb (rebase: avoid computing unnecessary
patch IDs, 2016-07-29), this avoids unnecessary work since not all
objects in the hashmap will eventually be compared.
Remove the ten-year-old "NEEDSWORK" comment and formally document
this intentional design trade-off.
Signed-off-by: Tian Yuchen <cat@malon.dev>
---
patch-ids.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/patch-ids.c b/patch-ids.c
index a5683b462c..1fbc88cbec 100644
--- a/patch-ids.c
+++ b/patch-ids.c
@@ -41,7 +41,14 @@ 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.
+ *
+ * Even though eptr and entry_or_key are const, we want to
+ * lazily compute their .patch_id members; see b3dfeebb (rebase:
+ * avoid computing unnecessary patch IDs, 2016-07-29). So we cast
+ * the constness away with container_of().
+ */
struct diff_options *opt = (void *)cmpfn_data;
struct patch_id *a, *b;
--
2.43.0
prev parent reply other threads:[~2026-03-09 6:52 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 ` [PATCH v2] patch-ids: document intentional const-casting " Tian Yuchen
2026-03-09 0:26 ` Junio C Hamano
2026-03-09 6:39 ` cat
2026-03-09 6:51 ` Tian Yuchen [this message]
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=20260309065140.108644-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.