[PATCH] ref-filter: clarify lstrip/rstrip component counting
- From
Jeff King <peff@peff.net>
- Date
- Feb 20, 2026, 06:00 UTC
- Message-ID
- <20260220060003.GA26256@coredump.intra.peff.net>
- In-Reply-To
- <xmqq8qco5zpm.fsf@gitster.g>
On Thu, Feb 19, 2026 at 10:56:53AM -0800, Junio C Hamano wrote:
Show 12 quoted lines
> > Is it worth rewriting to the "slashes" form above for clarity? I was > > afraid to touch it just to shut up Coverity, but now we have two > > confused people. > > Yup, I think the answer to my "what does p mean?" question is "by > itself p has *no* meaning, but (p-refname) is maintained to be the > number of non-slash bytes we scanned so far, while i is the number > of slashes." > > And from that point of view, your "count slashes in the most stupid > way that even 5 year old understands" certainly does make the result > far easier to read.
Here it is in patch form. Probably not worth as many words as I wrote in the commit message, but most of it is just summarizing our earlier findings.
I do notice that this function may not do what we want for "/absolute/ref/name" or for "refs//with//double//slashes". But I don't think it should see either of those, as it would always get normalized refnames from Git itself. So I think we can ignore it for now.
-- >8 -- Subject: [PATCH] ref-filter: clarify lstrip/rstrip component counting
When a strip option to the %(refname) placeholder is asked to leave N path components, we first count up the path components to know how many to remove. That happens with a loop like this:
/* Find total no of '/' separated path-components */ for (i = 0; p[i]; p[i] == '/' ? i++ : *p++) ;
which is a little hard to understand for two reasons.
First, the dereference in "*p++" is seemingly useless, since nobody looks at the result. And static analyzers like Coverity will complain about that. But removing the "*" will cause gcc to complain with -Wint-conversion, since the two sides of the ternary do not match (one is a pointer and the other an int).
Second, it is not clear what the meaning of "p" is at each iteration of the loop, as its position with respect to our walk over the string depends on how many slashes we've seen. The answer is that by itself, it doesn't really mean anything: "p + i" represents the current state of our walk, with "i" counting up slashes, and "p" by itself essentially meaningless.
None of this behaves incorrectly, but ultimately the loop is just counting the slashes in the refname. We can do that much more simply with a for-loop iterating over the string and a separate slash counter.
We can also drop the comment, which is somewhat misleading. We are counting slashes, not components (and a comment later in the function makes it clear that we must add one to compensate). In the new code it is obvious that we are counting slashes here.
Signed-off-by: Jeff King <peff@peff.net> --- ref-filter.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/ref-filter.c b/ref-filter.c index ac32b0e6bb..6bbb6fac18 100644 --- a/ref-filter.c +++ b/ref-filter.c @@ -2176,19 +2176,20 @@ static inline char *copy_advance(char *dst, const char *src) static int normalize_component_count(const char *refname, int len) { if (len < 0) { - int i; - const char *p = refname; + int slashes = 0; + + for (const char *p = refname; *p; p++) { + if (*p == '/') + slashes++; + } - /* Find total no of '/' separated path-components */ - for (i = 0; p[i]; p[i] == '/' ? i++ : *p++) - ; /* * The number of components we need to strip is now * the total minus the components to be left (Plus one * because we count the number of '/', but the number * of components is one more than the no of '/'). */ - len = i + len + 1; + len = slashes + len + 1; } return len; }
-- 2.53.0.528.g678f28d038