From: Jeff King <peff@peff.net>
Date: Sun, 15 Feb 2026 09:11:16 GMT
Subject: Re: [PATCH 0/4] cleaning up ref-filter lstrip/rstrip code
Message-ID: <20260215091116.GA695914@coredump.intra.peff.net>
In-Reply-To: <20260215085755.GA86262@coredump.intra.peff.net>

On Sun, Feb 15, 2026 at 03:57:55AM -0500, Jeff King wrote:

> > That is a bit of a seperate topic than fixing the warning, though, so
> > I left them as-is.
> 
> It is a separate topic, but I feel like this is a good opportunity to
> make this code less horrible. That is, there are some obvious
> low-hanging cleanups that make the code more readable, and as a side
> effect we clean up the const confusion. In such cases I think it is
> worth veering off the path a little.
> 
> I was going to catalog the numerous flaws I found, but by the time I
> explained them, I had basically written patches and commit messages. So
> here is what I would propose instead. I hope I'm not stealing your
> thunder nor knocking us too far off our goal.
> 
> The first three I hope are no-brainers, and the final one fixes the
> glibc const issue. The fourth is perhaps more risky.
> 
>   [1/4]: ref-filter: factor out refname component counting
>   [2/4]: ref-filter: simplify lstrip_ref_components() memory handling
>   [3/4]: ref-filter: simplify rstrip_ref_components() memory handling
>   [4/4]: ref-filter: open-code slash search in rstrip_ref_components()
> 
>  ref-filter.c | 54 +++++++++++++++++-----------------------------------
>  1 file changed, 17 insertions(+), 37 deletions(-)

BTW, you might notice one further opportunity for cleanup: these
functions return an allocated string via a "const char *". But that
issue is endemic to the ref-filter code, courtesy of f0062d3b74
(ref-filter: free item->value and item->value->s, 2018-10-18), and we
should probably look into cleaning it up all at once.

And that crosses my line of "way off topic, let's leave it for another
day". See, I do have _some_ restraint. ;)

-Peff