All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: tnyman@openai.com,  git@vger.kernel.org,  haraldnordgren@gmail.com
Subject: Re: [PATCH] branch: avoid slow strvec Coccinelle matching
Date: Fri, 24 Jul 2026 10:33:05 -0700	[thread overview]
Message-ID: <xmqqse5870oe.fsf@gitster.g> (raw)
In-Reply-To: <xmqqbjbw8icj.fsf@gitster.g> (Junio C. Hamano's message of "Fri, 24 Jul 2026 09:26:04 -0700")

Junio C Hamano <gitster@pobox.com> writes:

>> Ah, very good eyes.  It is a disease to try appeasing -Wsign-compare
>> without thinking, instead of questioning the value of the warning
>> first, and in this case there is no reason to try forcing the use of
>> size_t, even with the unnecessary casting.
>
> Having said that, another fix might be to standardize the way we
> count the number of things in an array and update 'ref-filter.h' to
> use size_t in 'struct ref_array' as well.
>
> It is not as though 2 billion refs are too few to satisfy our
> needs, and in general, the platform-natural int should be used to
> count things unless there is a compelling reason to deviate from
> that norm.  However, "somehow we ended up counting many things in
> size_t, so it is better to count everything using the same type"
> could serve as "the compelling reason" to make such a change.

Let's not allow too much latitude to ourselves, as that would only
confuse us.

Here is what I recommend that we do.  In the short term, i.e.,
within the context of the topic in question, let's use 'int' to
match the type used to count the members of an array embedded in
'struct ref_array'.

But let's leave a '#leftoverbits' note here in the mailing list
archive to remind us to revisit the idea of consistently using
'size_t' to count things when things are quiet.  This is not the
time to needlessly disrupt the 'hn/branch-delete-merged' topic, I
think.

  reply	other threads:[~2026-07-24 17:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-24  9:11 [PATCH] branch: avoid slow strvec Coccinelle matching tnyman
2026-07-24 11:49 ` Jeff King
2026-07-24 12:35   ` Harald Nordgren
2026-07-24 15:58   ` Junio C Hamano
2026-07-24 16:26     ` Junio C Hamano
2026-07-24 17:33       ` Junio C Hamano [this message]
2026-07-24 15:27 ` Junio C Hamano
2026-07-24 21:20   ` Taylor Blau

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=xmqqse5870oe.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=haraldnordgren@gmail.com \
    --cc=peff@peff.net \
    --cc=tnyman@openai.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.