{"thread":{"id":"66057","subject":"[PATCH] branch: avoid slow strvec Coccinelle matching","startedAt":"2026-07-24T09:11:54Z","lastAt":"2026-09-04T04:20:24Z","messageCount":11,"participants":["tnyman@openai.com","Jeff King","Harald Nordgren","Junio C Hamano","Taylor Blau","Emmanuel Ugwu"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"548865","messageId":"20260724091152.27794-2-tnyman@openai.com","threadId":"66057","inReplyTo":null,"subject":"[PATCH] branch: avoid slow strvec Coccinelle matching","fromName":"","fromEmail":"tnyman@openai.com","sentAt":"2026-07-24T09:11:53Z","receivedAt":"2026-07-24T09:11:54Z","isPatch":true,"body":"From: Ted Nyman \n\nThe --delete-merged implementation declares a loop index at function\nscope and reuses it to walk its strvec of upstreams and its list of\ncandidate branches. Coccinelle 1.1.1 spends hours matching this against\nthe separate_loop_index rule in tools/coccinelle/strvec.cocci, causing\nthe static-analysis job on 'seen' to reach its six-hour timeout.\n\nDeclare each index in its for loop instead. This avoids the expensive\nseparate-index rule, limits each index to the loop that uses it, and\nleaves the branch deletion behavior unchanged.\n\nSigned-off-by: Ted Nyman \n---\nThis applies on top of hn/branch-delete-merged and addresses the long\nstatic-analysis runs on 'seen'. Coccinelle 1.1.1 spends hours matching\nthe existing separate_loop_index rule against delete_merged_branches().\n\nDeclare each loop index in its for statement instead of sharing an\nindex declared at function scope. This avoids the pathological matching\nwithout changing branch behavior.\n\nThe CI failure reproduces locally with Coccinelle 1.1.1: applying\nstrvec.cocci to the original builtin/branch.c still times out with\n\"spatch --timeout 120\". With this change, the same check completes in\n0.06 seconds.\n\nThe full coccicheck run completes in 47 seconds, and all 190 tests in\nt3200-branch.sh pass with a fresh DEVELOPER=1 build.\n\n builtin/branch.c | 5 ++---\n 1 file changed, 2 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 42f2221547..2415a275ea 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -797,10 +797,9 @@ static int delete_merged_branches(const struct strvec *upstreams,\n \tstruct strbuf key = STRBUF_INIT;\n \tstruct hashmap_iter iter;\n \tstruct strmap_entry *entry;\n-\tsize_t i;\n \tint ret = 0;\n \n-\tfor (i = 0; i < upstreams->nr; i++)\n+\tfor (size_t i = 0; i < upstreams->nr; i++)\n \t\tif (ref_filter_forked_add(&filter, upstreams->v[i]) < 0)\n \t\t\tdie(_(\"'%s' is not a valid branch or pattern\"),\n \t\t\t upstreams->v[i]);\n@@ -809,7 +808,7 @@ static int delete_merged_branches(const struct strvec *upstreams,\n \tfilter.name_patterns = argv;\n \tfilter_refs(&candidates, &filter, filter.kind);\n \n-\tfor (i = 0; i < (size_t)candidates.nr; i++) {\n+\tfor (size_t i = 0; i < (size_t)candidates.nr; i++) {\n \t\tconst char *branch_refname = candidates.items[i]->refname;\n \t\tconst char *branch_name;\n \t\tstruct branch *branch;\n-- \n2.54.0.8.g047e0526de\n"},{"id":"548891","messageId":"20260724114948.GA825505@coredump.intra.peff.net","threadId":"66057","inReplyTo":"20260724091152.27794-2-tnyman@openai.com","subject":"Re: [PATCH] branch: avoid slow strvec Coccinelle matching","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-07-24T11:49:48Z","receivedAt":"2026-07-24T11:49:56Z","isPatch":true,"body":"On Fri, Jul 24, 2026 at 02:11:53AM -0700, tnyman@openai.com wrote:\n\n> The --delete-merged implementation declares a loop index at function\n> scope and reuses it to walk its strvec of upstreams and its list of\n> candidate branches. Coccinelle 1.1.1 spends hours matching this against\n> the separate_loop_index rule in tools/coccinelle/strvec.cocci, causing\n> the static-analysis job on 'seen' to reach its six-hour timeout.\n\nYuck. So this is really a coccinelle problem. It looks like it has been\nfixed (or at least improved) in recent versions. I can reproduce the\nslowness locally on 1.2.0 (I couldn't get 1.1.1 to build), but 1.3.0 is\nfast. Bisection turns up 58619b8fe (break up envs for e1 & e2,\n2024-08-18), which says:\n\n Since 362937b2a84840e68ae021171df10c7a4cc6fbef, e1 ... e2 has the\n quantifiers for the free variables of e1 around the whole thing, to ensure\n that the when code on the ... refers to the same variables as e1. This can\n make the semantic patch very slow, as illustrated by kmerr.cocci in\n scripts/coccinelle/null/kmerr.cocci in the Linux kernel. The slowness\n comes from environments based on multipl metavariable bindings getting very\n large.\n\n To reduce (but not solve) the problem, for the first & where the left side\n has multiple results, consider these results individually when working on\n the right side, and then union the results. This may lead to some loss of\n sharing. Maybe it is not advantageous when the ... contains when any and\n does not contain any explicit when clause containing the variables of e1.\n\nThe static-analysis CI job uses the ubuntu-22.04 image, for no reason\nthat I can really discern. It looks like coccinelle 1.3.0 is in ubuntu\n25.10, according to:\n\n https://packages.ubuntu.com/km/questing/coccinelle\n\nWhy don't we just use the more recent version instead of trying to work\naround it? That would fix this problem and prevent future ones. Looking\nat the code in question:\n\n> diff --git a/builtin/branch.c b/builtin/branch.c\n> index 42f2221547..2415a275ea 100644\n> --- a/builtin/branch.c\n> +++ b/builtin/branch.c\n> @@ -797,10 +797,9 @@ static int delete_merged_branches(const struct strvec *upstreams,\n> \tstruct strbuf key = STRBUF_INIT;\n> \tstruct hashmap_iter iter;\n> \tstruct strmap_entry *entry;\n> -\tsize_t i;\n> \tint ret = 0;\n> \n> -\tfor (i = 0; i < upstreams->nr; i++)\n> +\tfor (size_t i = 0; i < upstreams->nr; i++)\n> \t\tif (ref_filter_forked_add(&filter, upstreams->v[i]) < 0)\n> \t\t\tdie(_(\"'%s' is not a valid branch or pattern\"),\n> \t\t\t upstreams->v[i]);\n\n...there is nothing suspicious or wrong about it. It seems likely that\nsomebody else may end up writing something similar and triggering the\nsame problem.\n\nThat said, moving the iterator into the loop declaration is perhaps\nnicer anyway, because it avoids two unrelated uses of the same variable.\nNotably:\n\n> @@ -809,7 +808,7 @@ static int delete_merged_branches(const struct strvec *upstreams,\n> \tfilter.name_patterns = argv;\n> \tfilter_refs(&candidates, &filter, filter.kind);\n> \n> -\tfor (i = 0; i < (size_t)candidates.nr; i++) {\n> +\tfor (size_t i = 0; i < (size_t)candidates.nr; i++) {\n> \t\tconst char *branch_refname = candidates.items[i]->refname;\n> \t\tconst char *branch_name;\n> \t\tstruct branch *branch;\n\nThis hunk is not using a strvec at all. Because it uses the same\nvariable, if we did not change this loop, then we'd still have to\ndeclare \"i\" at the top of the function and the other loop would\nintroduce a shadowed variable. That's not wrong, but it is confusing.\n\nHowever, if we are going to have our own variable here, perhaps it\nshould use the correct type? candidate.nr is an int, so probably this\nshould also be an int, and then the gross cast can go away.\n\n-Peff\n"},{"id":"548892","messageId":"CAHwyqnVNjspjWkiu3Gq-jde_M+hX9x5RfjxoC-3Wzfin_JZuqg@mail.gmail.com","threadId":"66057","inReplyTo":"20260724114948.GA825505@coredump.intra.peff.net","subject":"Re: [PATCH] branch: avoid slow strvec Coccinelle matching","fromName":"Harald Nordgren","fromEmail":"haraldnordgren@gmail.com","sentAt":"2026-07-24T12:35:06Z","receivedAt":"2026-07-24T12:35:44Z","isPatch":true,"body":"Thanks for the report, Ted! CI had been timing out on this branch, but\nI chalked it up to one of the many CI failures we had in the last few\nmonths. CI is now generally stable again for some days, and with your\nfix it's also green on this branch specifically.\n\nGood point, Jeff, probably it can be 'int i' in the 'candidates.nr',\ncase to avoid a cast. I'll push it to GitHub to verify that the CI\npasses there as well, but I'll wait with submitting until others have\nfinished reviewing, to not overload inboxes after already pushing out\none version today.\n\n\nHarald\n"},{"id":"548895","messageId":"xmqq33x89zn9.fsf@gitster.g","threadId":"66057","inReplyTo":"20260724091152.27794-2-tnyman@openai.com","subject":"Re: [PATCH] branch: avoid slow strvec Coccinelle matching","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-24T15:27:06Z","receivedAt":"2026-07-24T15:27:09Z","isPatch":true,"body":"tnyman@openai.com writes:\n\n> From: Ted Nyman \n>\n> The --delete-merged implementation declares a loop index at function\n> scope and reuses it to walk its strvec of upstreams and its list of\n> candidate branches. Coccinelle 1.1.1 spends hours matching this against\n> the separate_loop_index rule in tools/coccinelle/strvec.cocci, causing\n> the static-analysis job on 'seen' to reach its six-hour timeout.\n> ...\n> The CI failure reproduces locally with Coccinelle 1.1.1: applying\n> strvec.cocci to the original builtin/branch.c still times out with\n> \"spatch --timeout 120\". With this change, the same check completes in\n> 0.06 seconds.\n\nImpressive. Nicely analyzed.\n\nEven though this is very much like bending the code only to appease\nthe checker, the resulting code is arguably better in this\nparticular case, so I do not feel as bad as I have on other\noccasions when we had to work around deficiencies in our tools [*].\n\nI see Harald already took this in the latest update. Thanks for\nworking well together.\n\n[*]\n\n * Here, I do not blame Coccinelle alone. The performance bug is\n caused by a combination of Coccinelle and the 'strvec' check that\n makes it so inefficient. I wonder if there are ways to make the\n checks in 'strvec.cocci' more efficient?\n\n\n> diff --git a/builtin/branch.c b/builtin/branch.c\n> index 42f2221547..2415a275ea 100644\n> --- a/builtin/branch.c\n> +++ b/builtin/branch.c\n> @@ -797,10 +797,9 @@ static int delete_merged_branches(const struct strvec *upstreams,\n> \tstruct strbuf key = STRBUF_INIT;\n> \tstruct hashmap_iter iter;\n> \tstruct strmap_entry *entry;\n> -\tsize_t i;\n> \tint ret = 0;\n> \n> -\tfor (i = 0; i < upstreams->nr; i++)\n> +\tfor (size_t i = 0; i < upstreams->nr; i++)\n> \t\tif (ref_filter_forked_add(&filter, upstreams->v[i]) < 0)\n> \t\t\tdie(_(\"'%s' is not a valid branch or pattern\"),\n> \t\t\t upstreams->v[i]);\n> @@ -809,7 +808,7 @@ static int delete_merged_branches(const struct strvec *upstreams,\n> \tfilter.name_patterns = argv;\n> \tfilter_refs(&candidates, &filter, filter.kind);\n> \n> -\tfor (i = 0; i < (size_t)candidates.nr; i++) {\n> +\tfor (size_t i = 0; i < (size_t)candidates.nr; i++) {\n> \t\tconst char *branch_refname = candidates.items[i]->refname;\n> \t\tconst char *branch_name;\n> \t\tstruct branch *branch;\n"},{"id":"548898","messageId":"xmqqpl0c8jml.fsf@gitster.g","threadId":"66057","inReplyTo":"20260724114948.GA825505@coredump.intra.peff.net","subject":"Re: [PATCH] branch: avoid slow strvec Coccinelle matching","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-24T15:58:26Z","receivedAt":"2026-07-24T15:58:29Z","isPatch":true,"body":"Jeff King writes:\n\n> The static-analysis CI job uses the ubuntu-22.04 image, for no reason\n> that I can really discern. It looks like coccinelle 1.3.0 is in ubuntu\n> 25.10, according to:\n>\n> https://packages.ubuntu.com/km/questing/coccinelle\n>\n> Why don't we just use the more recent version instead of trying to work\n> around it? That would fix this problem and prevent future ones. Looking\n> at the code in question:\n>\n>> diff --git a/builtin/branch.c b/builtin/branch.c\n>> index 42f2221547..2415a275ea 100644\n>> --- a/builtin/branch.c\n>> +++ b/builtin/branch.c\n>> @@ -797,10 +797,9 @@ static int delete_merged_branches(const struct strvec *upstreams,\n>> \tstruct strbuf key = STRBUF_INIT;\n>> \tstruct hashmap_iter iter;\n>> \tstruct strmap_entry *entry;\n>> -\tsize_t i;\n>> \tint ret = 0;\n>> \n>> -\tfor (i = 0; i < upstreams->nr; i++)\n>> +\tfor (size_t i = 0; i < upstreams->nr; i++)\n>> \t\tif (ref_filter_forked_add(&filter, upstreams->v[i]) < 0)\n>> \t\t\tdie(_(\"'%s' is not a valid branch or pattern\"),\n>> \t\t\t upstreams->v[i]);\n>\n> ...there is nothing suspicious or wrong about it. It seems likely that\n> somebody else may end up writing something similar and triggering the\n> same problem.\n\nExactly.\n\n> That said, moving the iterator into the loop declaration is perhaps\n> nicer anyway, because it avoids two unrelated uses of the same variable.\n\nExactly again.\n\n> Notably:\n>\n>> @@ -809,7 +808,7 @@ static int delete_merged_branches(const struct strvec *upstreams,\n>> \tfilter.name_patterns = argv;\n>> \tfilter_refs(&candidates, &filter, filter.kind);\n>> \n>> -\tfor (i = 0; i < (size_t)candidates.nr; i++) {\n>> +\tfor (size_t i = 0; i < (size_t)candidates.nr; i++) {\n>> \t\tconst char *branch_refname = candidates.items[i]->refname;\n>> \t\tconst char *branch_name;\n>> \t\tstruct branch *branch;\n>\n> This hunk is not using a strvec at all. Because it uses the same\n> variable, if we did not change this loop, then we'd still have to\n> declare \"i\" at the top of the function and the other loop would\n> introduce a shadowed variable. That's not wrong, but it is confusing.\n>\n> However, if we are going to have our own variable here, perhaps it\n> should use the correct type? candidate.nr is an int, so probably this\n> should also be an int, and then the gross cast can go away.\n\nAh, very good eyes. It is a disease to try appeasing -Wsign-compare\nwithout thinking, instead of questioning the value of the warning\nfirst, and in this case there is no reason to try forcing the use of\nsize_t, even with the unnecessary casting.\n\n"},{"id":"548900","messageId":"xmqqbjbw8icj.fsf@gitster.g","threadId":"66057","inReplyTo":"xmqqpl0c8jml.fsf@gitster.g","subject":"Re: [PATCH] branch: avoid slow strvec Coccinelle matching","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-24T16:26:04Z","receivedAt":"2026-07-24T16:26:06Z","isPatch":true,"body":"Junio C Hamano writes:\n\n>> Notably:\n>>\n>>> @@ -809,7 +808,7 @@ static int delete_merged_branches(const struct strvec *upstreams,\n>>> \tfilter.name_patterns = argv;\n>>> \tfilter_refs(&candidates, &filter, filter.kind);\n>>> \n>>> -\tfor (i = 0; i < (size_t)candidates.nr; i++) {\n>>> +\tfor (size_t i = 0; i < (size_t)candidates.nr; i++) {\n>>> \t\tconst char *branch_refname = candidates.items[i]->refname;\n>>> \t\tconst char *branch_name;\n>>> \t\tstruct branch *branch;\n>>\n>> This hunk is not using a strvec at all. Because it uses the same\n>> variable, if we did not change this loop, then we'd still have to\n>> declare \"i\" at the top of the function and the other loop would\n>> introduce a shadowed variable. That's not wrong, but it is confusing.\n>>\n>> However, if we are going to have our own variable here, perhaps it\n>> should use the correct type? candidate.nr is an int, so probably this\n>> should also be an int, and then the gross cast can go away.\n>\n> Ah, very good eyes. It is a disease to try appeasing -Wsign-compare\n> without thinking, instead of questioning the value of the warning\n> first, and in this case there is no reason to try forcing the use of\n> size_t, even with the unnecessary casting.\n\nHaving said that, another fix might be to standardize the way we\ncount the number of things in an array and update 'ref-filter.h' to\nuse size_t in 'struct ref_array' as well.\n\nIt is not as though 2 billion refs are too few to satisfy our\nneeds, and in general, the platform-natural int should be used to\ncount things unless there is a compelling reason to deviate from\nthat norm. However, \"somehow we ended up counting many things in\nsize_t, so it is better to count everything using the same type\"\ncould serve as \"the compelling reason\" to make such a change.\n"},{"id":"548902","messageId":"xmqqse5870oe.fsf@gitster.g","threadId":"66057","inReplyTo":"xmqqbjbw8icj.fsf@gitster.g","subject":"Re: [PATCH] branch: avoid slow strvec Coccinelle matching","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-24T17:33:05Z","receivedAt":"2026-07-24T17:33:08Z","isPatch":true,"body":"Junio C Hamano writes:\n\n>> Ah, very good eyes. It is a disease to try appeasing -Wsign-compare\n>> without thinking, instead of questioning the value of the warning\n>> first, and in this case there is no reason to try forcing the use of\n>> size_t, even with the unnecessary casting.\n>\n> Having said that, another fix might be to standardize the way we\n> count the number of things in an array and update 'ref-filter.h' to\n> use size_t in 'struct ref_array' as well.\n>\n> It is not as though 2 billion refs are too few to satisfy our\n> needs, and in general, the platform-natural int should be used to\n> count things unless there is a compelling reason to deviate from\n> that norm. However, \"somehow we ended up counting many things in\n> size_t, so it is better to count everything using the same type\"\n> could serve as \"the compelling reason\" to make such a change.\n\nLet's not allow too much latitude to ourselves, as that would only\nconfuse us.\n\nHere is what I recommend that we do. In the short term, i.e.,\nwithin the context of the topic in question, let's use 'int' to\nmatch the type used to count the members of an array embedded in\n'struct ref_array'.\n\nBut let's leave a '#leftoverbits' note here in the mailing list\narchive to remind us to revisit the idea of consistently using\n'size_t' to count things when things are quiet. This is not the\ntime to needlessly disrupt the 'hn/branch-delete-merged' topic, I\nthink.\n"},{"id":"548926","messageId":"amPXKfnoTzUuuyMN@com-79390","threadId":"66057","inReplyTo":"xmqq33x89zn9.fsf@gitster.g","subject":"Re: [PATCH] branch: avoid slow strvec Coccinelle matching","fromName":"Taylor Blau","fromEmail":"ttaylorr@openai.com","sentAt":"2026-07-24T21:20:41Z","receivedAt":"2026-07-24T21:20:46Z","isPatch":true,"body":"On Fri, Jul 24, 2026 at 08:27:06AM -0700, Junio C Hamano wrote:\n> tnyman@openai.com writes:\n>\n> > From: Ted Nyman \n> >\n> > The --delete-merged implementation declares a loop index at function\n> > scope and reuses it to walk its strvec of upstreams and its list of\n> > candidate branches. Coccinelle 1.1.1 spends hours matching this against\n> > the separate_loop_index rule in tools/coccinelle/strvec.cocci, causing\n> > the static-analysis job on 'seen' to reach its six-hour timeout.\n> > ...\n> > The CI failure reproduces locally with Coccinelle 1.1.1: applying\n> > strvec.cocci to the original builtin/branch.c still times out with\n> > \"spatch --timeout 120\". With this change, the same check completes in\n> > 0.06 seconds.\n>\n> Impressive. Nicely analyzed.\n>\n> Even though this is very much like bending the code only to appease\n> the checker, the resulting code is arguably better in this\n> particular case, so I do not feel as bad as I have on other\n> occasions when we had to work around deficiencies in our tools [*].\n\nAgreed. I don't think we should ever bend over backwards to appease a\nstatic analysis tool, *especially* when it results in worse looking\ncode. But this case is a strict improvement, and just so happens to\naddress the Coccinelle issue. ;-)\n\n> I see Harald already took this in the latest update. Thanks for\n> working well together.\n\nYup. Thanks, both.\n\nThanks,\nTaylor\n"},{"id":"548986","messageId":"20260726074100.GA2366012@coredump.intra.peff.net","threadId":"66057","inReplyTo":"xmqqbjbw8icj.fsf@gitster.g","subject":"Re: [PATCH] branch: avoid slow strvec Coccinelle matching","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-07-26T07:41:00Z","receivedAt":"2026-07-26T07:41:02Z","isPatch":true,"body":"On Fri, Jul 24, 2026 at 09:26:04AM -0700, Junio C Hamano wrote:\n\n> > Ah, very good eyes. It is a disease to try appeasing -Wsign-compare\n> > without thinking, instead of questioning the value of the warning\n> > first, and in this case there is no reason to try forcing the use of\n> > size_t, even with the unnecessary casting.\n> \n> Having said that, another fix might be to standardize the way we\n> count the number of things in an array and update 'ref-filter.h' to\n> use size_t in 'struct ref_array' as well.\n\nYes, I had the same thought.\n\nI am generally in favor of using size_t for anything that counts\nallocations. I'd also be fine with (and maybe even prefer) a type that\nis a signed integer of the same magnitude as size_t, because loops, etc,\nare often easier to reason about when \"0 - 1\" is actually less than 0,\nand doesn't wrap. But we would need to define our own custom type for\nthat, since ssize_t isn't portable enough.\n\n> It is not as though 2 billion refs are too few to satisfy our\n> needs, and in general, the platform-natural int should be used to\n> count things unless there is a compelling reason to deviate from\n> that norm. However, \"somehow we ended up counting many things in\n> size_t, so it is better to count everything using the same type\"\n> could serve as \"the compelling reason\" to make such a change.\n\nYeah, I think that consistency is nice.\n\nMy personal reason (and this is mostly re-hashing previous discussions)\nis avoiding integer overflow attacks by making it impractical to\nallocate sufficient memory.\n\nIf you had a repository with 3 billion refs, then I think right now \"git\nfor-each-ref\" would wrap and start using negative values. I _suspect_ it\nwould be caught when ALLOC_GROW() converts that negative into to a\nsize_t (yielding an impractical allocation), but I don't think it's\npractical to try. I started feeding 2^31 refs into \"update-ref --stdin\"\nand it was around 64GB of heap after only 160 million or so.\n\nBut in general, if the counters are all size_t or similar magnitude,\nthen any geometric growth pattern is going to require allocating some\nsignificant portion of the whole address space before we hit the integer\noverflow condition (and presumably such an allocation would fail).\n\n-Peff\n"},{"id":"548987","messageId":"20260726074122.GB2366012@coredump.intra.peff.net","threadId":"66057","inReplyTo":"xmqqse5870oe.fsf@gitster.g","subject":"Re: [PATCH] branch: avoid slow strvec Coccinelle matching","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-07-26T07:41:22Z","receivedAt":"2026-07-26T07:41:23Z","isPatch":true,"body":"On Fri, Jul 24, 2026 at 10:33:05AM -0700, Junio C Hamano wrote:\n\n> Here is what I recommend that we do. In the short term, i.e.,\n> within the context of the topic in question, let's use 'int' to\n> match the type used to count the members of an array embedded in\n> 'struct ref_array'.\n> \n> But let's leave a '#leftoverbits' note here in the mailing list\n> archive to remind us to revisit the idea of consistently using\n> 'size_t' to count things when things are quiet. This is not the\n> time to needlessly disrupt the 'hn/branch-delete-merged' topic, I\n> think.\n\nYep, agreed on all points.\n\n-Peff\n"},{"id":"551923","messageId":"CALk1092+d4kazT-cQuN3Xih2cJNBC8mBAbyR0YPELWT37K9KDg@mail.gmail.com","threadId":"66057","inReplyTo":"20260726074122.GB2366012@coredump.intra.peff.net","subject":"Re: [PATCH] branch: avoid slow strvec Coccinelle matching","fromName":"Emmanuel Ugwu","fromEmail":"emmanuelugwu121@gmail.com","sentAt":"2026-09-04T04:20:11Z","receivedAt":"2026-09-04T04:20:24Z","isPatch":true,"body":"Hi Junio, Jeff,\n\nI'm Emmanuel Ugwu, new to the project and looking to get involved.\nI noticed this #leftoverbits from\n.\nI have gone through the thread, the desired fix is to fix the inconsistencies\nin type by choosing/using a wide-enough type to avoid overflow (size_t) right?\n\nIs now a reasonable time to start looking into this, or would you\nrather it wait until 'hn/branch-delete-merged' has settled?\n\nThanks,\nEmmanuel Ugwu\n\nOn Sun, Jul 26, 2026 at 8:41 AM Jeff King wrote:\n>\n> On Fri, Jul 24, 2026 at 10:33:05AM -0700, Junio C Hamano wrote:\n>\n> > Here is what I recommend that we do. In the short term, i.e.,\n> > within the context of the topic in question, let's use 'int' to\n> > match the type used to count the members of an array embedded in\n> > 'struct ref_array'.\n> >\n> > But let's leave a '#leftoverbits' note here in the mailing list\n> > archive to remind us to revisit the idea of consistently using\n> > 'size_t' to count things when things are quiet. This is not the\n> > time to needlessly disrupt the 'hn/branch-delete-merged' topic, I\n> > think.\n>\n> Yep, agreed on all points.\n>\n> -Peff\n>\n"}]}