public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Pushkar Singh <pushkarkumarsingh1970@gmail.com>
Cc: git@vger.kernel.org,  peff@peff.net
Subject: Re: [PATCH] path: refactor normalize_path_copy_len()
Date: Thu, 29 Jan 2026 10:54:31 -0800	[thread overview]
Message-ID: <xmqqh5s4b66w.fsf@gitster.g> (raw)
In-Reply-To: <20260129145434.29123-2-pushkarkumarsingh1970@gmail.com> (Pushkar Singh's message of "Thu, 29 Jan 2026 14:54:35 +0000")

Pushkar Singh <pushkarkumarsingh1970@gmail.com> writes:

> Refactor normalize_path_copy_len() by extracting helpers for skipping
> slashes, handling dot components, and stripping the previous path
> component, making the control flow easier to follow.

The new helper for skip_slashes() may be a clear win as it extracts
away verbosity from 3 places.

Moving the logic to the "handle_dot_component()" helper, however,
dissociates the actual code from the explanation on the 4 special
cases in the comment, and at least to me, made it a lot harder to
understand what is being done and why.  Also the "goto up_one" logic
was easier to follow in the original than with the magic return
values given by the new helper.  Quite honestly, use of that helper
function looked like worsening the readablity of the logic.

Giving a descriptive name to what is done at the up_one label by
using a single-shot helper function strip_last_component() may be an
improvement, but I do not think it is a clear win.  Adding a
single-liner /* strip the last component */ comment without moving
the code may have made the result even easier to follow without
disrupting the flow with an extra helper function.

 path.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git i/path.c w/path.c
index d726537622..53a87ab67a 100644
--- i/path.c
+++ w/path.c
@@ -1182,6 +1182,8 @@ int normalize_path_copy_len(char *dst, const char *src, int *prefix_len)
 
 	up_one:
 		/*
+		 * strip the last component
+		 *
 		 * dst0..dst is prefix portion, and dst[-1] is '/';
 		 * go up one level.
 		 */

  reply	other threads:[~2026-01-29 18:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-29 14:54 [PATCH] path: refactor normalize_path_copy_len() Pushkar Singh
2026-01-29 18:54 ` Junio C Hamano [this message]
2026-01-30 14:01   ` [PATCH v2] path: factor out skip_slashes() in normalize_path_copy_len() Pushkar Singh
2026-02-14  9:13     ` Pushkar Singh
2026-02-17 18:27       ` Junio C Hamano
2026-02-21 11:05         ` [PATCH v3] " Pushkar Singh

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=xmqqh5s4b66w.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=pushkarkumarsingh1970@gmail.com \
    /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