git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] branch: avoid slow strvec Coccinelle matching

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 24, 2026, 16:26 UTC
Message-ID
<xmqqbjbw8icj.fsf@gitster.g>
In-Reply-To
<xmqqpl0c8jml.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
Show 25 quoted lines
>> Notably:
>>
>>> @@ -809,7 +808,7 @@ static int delete_merged_branches(const struct strvec *upstreams,
>>>  	filter.name_patterns = argv;
>>>  	filter_refs(&candidates, &filter, filter.kind);
>>>  
>>> -	for (i = 0; i < (size_t)candidates.nr; i++) {
>>> +	for (size_t i = 0; i < (size_t)candidates.nr; i++) {
>>>  		const char *branch_refname = candidates.items[i]->refname;
>>>  		const char *branch_name;
>>>  		struct branch *branch;
>>
>> This hunk is not using a strvec at all. Because it uses the same
>> variable, if we did not change this loop, then we'd still have to
>> declare "i" at the top of the function and the other loop would
>> introduce a shadowed variable. That's not wrong, but it is confusing.
>>
>> However, if we are going to have our own variable here, perhaps it
>> should use the correct type? candidate.nr is an int, so probably this
>> should also be an int, and then the gross cast can go away.
>
> 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.

Previous: Junio C HamanoNext: Junio C Hamano
Message 5 of 11 in “branch: avoid slow strvec Coccinelle matching”
  1. branch: avoid slow strvec Coccinelle matchingtnyman@openai.com, Jul 24, 2026
  2. Jeff KingJul 24, 2026
  3. Harald NordgrenJul 24, 2026
  4. Junio C HamanoJul 24, 2026
  5. Junio C HamanoJul 24, 2026
  6. Junio C HamanoJul 24, 2026
  7. Jeff KingJul 26, 2026
  8. Emmanuel UgwuSep 4, 2026
  9. Jeff KingJul 26, 2026
  10. Junio C HamanoJul 24, 2026
  11. Taylor BlauJul 24, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.