From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Collin Funk <collin.funk1@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH 1/4] ref-filter: factor out refname component counting
Date: Tue, 17 Feb 2026 10:07:29 -0800 [thread overview]
Message-ID: <xmqqqzqjckgu.fsf@gitster.g> (raw)
In-Reply-To: <20260215090052.GA695631@coredump.intra.peff.net> (Jeff King's message of "Sun, 15 Feb 2026 04:00:52 -0500")
Jeff King <peff@peff.net> writes:
> + if (len < 0) {
> + int i;
> + const char *p = refname;
> +
> + /* Find total no of '/' separated path-components */
> + for (i = 0; p[i]; p[i] == '/' ? i++ : *p++)
> + ;
Sorry, but I have no idea what this loop (copied verbatim from the
original) is trying to do.
We start at the beginning of the refname string, and while we are in
the leading run of '/' we increment i to find the end of that
run. E.g., we start with refname="///foo", p points at the leftmost
'/', i runs from 0 to 3 at which point p[i] points at the first
non-'/' character, at which point we do *p++, to make p point at the
second slash? Is the dereferencing of the pointer in *p++ a no-op
that is there only to confuse readers?
And then p moves to the right until p[i] points at the end of the
string. It does count the number of slashes in 'i', but there is no
satisfying simple answer to this question: "what does p mean while
this loop runs?".
Anyway, the conversion looks very faithful to the original.
next prev parent reply other threads:[~2026-02-17 18:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-14 5:15 [PATCH] ref-filter: don't declare a strdup'd variable const before writing to it Collin Funk
2026-02-15 8:57 ` [PATCH 0/4] cleaning up ref-filter lstrip/rstrip code Jeff King
2026-02-15 9:00 ` [PATCH 1/4] ref-filter: factor out refname component counting Jeff King
2026-02-17 18:07 ` Junio C Hamano [this message]
2026-02-19 11:21 ` Jeff King
2026-02-19 18:56 ` Junio C Hamano
2026-02-20 6:00 ` [PATCH] ref-filter: clarify lstrip/rstrip " Jeff King
2026-02-22 17:04 ` [PATCH 1/4] ref-filter: factor out refname " Karthik Nayak
2026-02-15 9:02 ` [PATCH 2/4] ref-filter: simplify lstrip_ref_components() memory handling Jeff King
2026-02-15 9:05 ` [PATCH 3/4] ref-filter: simplify rstrip_ref_components() " Jeff King
2026-02-15 9:07 ` [PATCH 4/4] ref-filter: avoid strrchr() in rstrip_ref_components() Jeff King
2026-02-16 7:23 ` Patrick Steinhardt
2026-02-15 9:11 ` [PATCH 0/4] cleaning up ref-filter lstrip/rstrip code Jeff King
2026-02-15 22:23 ` Collin Funk
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=xmqqqzqjckgu.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=collin.funk1@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox