From: Junio C Hamano <gitster@pobox.com>
To: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
Cc: git@vger.kernel.org, jltobler@gmail.com,
lucasseikioshiro@gmail.com, phillip.wood@dunelm.org.uk,
sandals@crustytoothpaste.net, kumarayushjha123@gmail.com,
a3205153416@gmail.com, kristofferhaugsbakk@fastmail.com
Subject: Re: [GSoC Patch v6 1/4] path: introduce append_formatted_path() for shared path formatting
Date: Sat, 20 Jun 2026 07:27:41 -0700 [thread overview]
Message-ID: <xmqqbjd5guci.fsf@gitster.g> (raw)
In-Reply-To: <20260620031644.353772-2-jayatheerthkulkarni2005@gmail.com> (K. Jayatheerth's message of "Sat, 20 Jun 2026 08:46:41 +0530")
K Jayatheerth <jayatheerthkulkarni2005@gmail.com> writes:
> The path-formatting logic in builtin/rev-parse.c is tightly coupled
> to that command and writes directly to stdout, making it impossible
> for other builtins to reuse.
>
> Extract the core algorithm into append_formatted_path() in path.c
> and expose a path_format enum in path.h so that any builtin can
> format paths consistently without duplicating logic.
>
> Mentored-by: Justin Tobler <jltobler@gmail.com>
> Mentored-by: Lucas Seiki Oshiro <lucasseikioshiro@gmail.com>
> Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
> ---
> path.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> path.h | 30 +++++++++++++++++++++++++
> 2 files changed, 99 insertions(+)
It often, even though not always, is a sign of a bad topic structure
to have an insertion-only patch without any removal of existing
code, that adds totally unused code.
If the step is to "extract the core algorithm", shouldn't it be able
to replace existing code already?
We may want to add new features to this helper function near the end
of the topic, but wouldn't it make sense for the topic to first
consolidate various path formatting logic already present in the
existing code into a single helper for ease of extending it (which
means replacing open-coded logic in existing code paths with a call
to the new helper, which would have a code that may look very
similar to the original code that was replaced with a single call to
the helper function), and then expose the helper for use by new
callers, and finally further add new features that existing code
paths wouldn't have needed but the new callers would want?
How else can we make sure this new implementation added by the first
step in the series is (1) capable enough to reproduce what we
already have in different parts of the system, (2) does not bring in
what the current codebase does not need, and (3) bug-to-bug
compatible with the existing code paths?
> diff --git a/path.c b/path.c
> index d7e17bf174..6d8e892ada 100644
> --- a/path.c
> +++ b/path.c
> @@ -1579,6 +1579,75 @@ char *xdg_cache_home(const char *filename)
> return NULL;
> }
>
> +void append_formatted_path(struct strbuf *dest, const char *path,
> + const char *prefix, enum path_format format)
> +{
> + switch (format) {
> + case PATH_FORMAT_UNMODIFIED:
> + strbuf_addstr(dest, path);
> + break;
> +
> + case PATH_FORMAT_RELATIVE: {
> + struct strbuf relative_buf = STRBUF_INIT;
> + struct strbuf real_path = STRBUF_INIT;
> + struct strbuf real_prefix = STRBUF_INIT;
> + char *cwd = NULL;
> +
> + /*
> + * We don't ever produce a relative path if prefix is NULL,
> + * so set the prefix to the current directory so that we can
> + * produce a relative path whenever possible.
> + */
> + if (!prefix)
> + prefix = cwd = xgetcwd();
> +
> + if (!is_absolute_path(path)) {
> + strbuf_realpath_forgiving(&real_path, path, 1);
> + path = real_path.buf;
> + }
> + if (!is_absolute_path(prefix)) {
> + strbuf_realpath_forgiving(&real_prefix, prefix, 1);
> + prefix = real_prefix.buf;
> + }
> +
> + strbuf_addstr(dest, relative_path(path, prefix, &relative_buf));
> +
> + strbuf_release(&relative_buf);
> + strbuf_release(&real_path);
> + strbuf_release(&real_prefix);
> + free(cwd);
> + break;
> + }
> +
> + case PATH_FORMAT_RELATIVE_IF_SHARED: {
> + struct strbuf relative_buf = STRBUF_INIT;
> +
> + /*
> + * If we're using RELATIVE_IF_SHARED mode, then we want an
> + * absolute path unless the two share a common prefix, so don't
> + * default the prefix to the current working directory. Doing so
> + * would cause a relative path to always be produced if possible.
> + */
> + strbuf_addstr(dest, relative_path(path, prefix, &relative_buf));
> + strbuf_release(&relative_buf);
> + break;
> + }
> +
> + case PATH_FORMAT_CANONICAL: {
> + struct strbuf canonical_buf = STRBUF_INIT;
> +
> + strbuf_realpath_forgiving(&canonical_buf, path, 1);
> + strbuf_addbuf(dest, &canonical_buf);
> +
> + strbuf_release(&canonical_buf);
> + break;
> + }
> +
> + default:
> + BUG("unknown path_format value %d", format);
> + }
> +}
> +
> REPO_GIT_PATH_FUNC(squash_msg, "SQUASH_MSG")
> REPO_GIT_PATH_FUNC(merge_msg, "MERGE_MSG")
> REPO_GIT_PATH_FUNC(merge_rr, "MERGE_RR")
> diff --git a/path.h b/path.h
> index 4c2958a903..4d982a2c8e 100644
> --- a/path.h
> +++ b/path.h
> @@ -262,6 +262,36 @@ enum scld_error safe_create_leading_directories_no_share(char *path);
> int safe_create_file_with_leading_directories(struct repository *repo,
> const char *path);
>
> +/**
> + * The formatting strategy to apply when writing a path into a buffer.
> + */
> +enum path_format {
> + /* Output the path exactly as-is without any modifications. */
> + PATH_FORMAT_UNMODIFIED,
> +
> + /* Output a path relative to the provided directory prefix. */
> + PATH_FORMAT_RELATIVE,
> +
> + /* Output a relative path only if the path shares a root with the prefix. */
> + PATH_FORMAT_RELATIVE_IF_SHARED,
> +
> + /* Output a fully resolved, absolute canonical path. */
> + PATH_FORMAT_CANONICAL
> +};
> +
> +/**
> + * Format a path according to the specified formatting strategy and append
> + * the result to the given strbuf.
> + *
> + * `dest` : The string buffer to append the formatted path to.
> + * `path` : The path string that needs to be formatted.
> + * `prefix` : The directory prefix to calculate relative offsets against.
> + * Pass NULL to default to the current working directory where applicable.
> + * `format` : The formatting behavior rule to execute.
> + */
> +void append_formatted_path(struct strbuf *dest, const char *path,
> + const char *prefix, enum path_format format);
> +
> # ifdef USE_THE_REPOSITORY_VARIABLE
> # include "strbuf.h"
> # include "repository.h"
next prev parent reply other threads:[~2026-06-20 14:27 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 15:19 [GSoC][PATCH 0/4] teach git repo info to handle path keys K Jayatheerth
2026-06-01 15:19 ` [GSoC][PATCH 1/4] path: add strbuf_add_path for formatting paths K Jayatheerth
2026-06-02 13:00 ` Phillip Wood
2026-06-01 15:19 ` [GSoC][PATCH 2/4] rev-parse: use strbuf_add_path for path formatting K Jayatheerth
2026-06-01 15:19 ` [GSoC][PATCH 3/4] repo: add path.gitdir with absolute and relative suffix formatting K Jayatheerth
2026-06-01 16:28 ` Lucas Seiki Oshiro
2026-06-01 23:09 ` Junio C Hamano
2026-06-01 15:19 ` [GSoC][PATCH 4/4] repo: add path.commondir " K Jayatheerth
2026-06-01 16:34 ` Lucas Seiki Oshiro
2026-06-01 21:58 ` Lucas Seiki Oshiro
2026-06-01 16:25 ` [GSoC][PATCH 0/4] teach git repo info to handle path keys Lucas Seiki Oshiro
2026-06-01 22:04 ` Lucas Seiki Oshiro
2026-06-01 23:05 ` Junio C Hamano
2026-06-02 13:03 ` Phillip Wood
2026-06-05 16:30 ` [GSoC PATCH v2 " K Jayatheerth
2026-06-05 16:30 ` [GSoC PATCH v2 1/4] path: introduce format_path() for centralized path formatting K Jayatheerth
2026-06-05 16:55 ` Kristoffer Haugsbakk
2026-06-09 2:27 ` K Jayatheerth
2026-06-08 15:05 ` Lucas Seiki Oshiro
2026-06-09 2:47 ` K Jayatheerth
2026-06-08 17:28 ` Justin Tobler
2026-06-05 16:30 ` [GSoC PATCH v2 2/4] rev-parse: use format_path for " K Jayatheerth
2026-06-08 17:54 ` Justin Tobler
2026-06-05 16:30 ` [GSoC PATCH v2 3/4] repo: add path.gitdir with absolute and relative suffix formatting K Jayatheerth
2026-06-08 18:50 ` Justin Tobler
2026-06-09 4:41 ` K Jayatheerth
2026-06-09 14:31 ` Justin Tobler
2026-06-10 12:11 ` K Jayatheerth
2026-06-08 22:17 ` Lucas Seiki Oshiro
2026-06-05 16:30 ` [GSoC PATCH v2 4/4] repo: add path.commondir " K Jayatheerth
2026-06-08 22:40 ` Lucas Seiki Oshiro
2026-06-05 17:35 ` [GSoC PATCH v2 0/4] teach git repo info to handle path keys Lucas Seiki Oshiro
2026-06-09 2:30 ` K Jayatheerth
2026-06-08 22:36 ` Junio C Hamano
2026-06-09 5:00 ` K Jayatheerth
2026-06-10 12:42 ` Lucas Seiki Oshiro
2026-06-12 18:28 ` [GSoC Patch v3 " K Jayatheerth
2026-06-12 18:28 ` [GSoC Patch v3 1/4] path: introduce append_formatted_path() for shared path formatting K Jayatheerth
2026-06-12 18:28 ` [GSoC Patch v3 2/4] rev-parse: use append_formatted_path() for " K Jayatheerth
2026-06-12 18:28 ` [GSoC Patch v3 3/4] repo: add path.commondir with absolute and relative suffix formatting K Jayatheerth
2026-06-15 1:54 ` Lucas Seiki Oshiro
2026-06-12 18:28 ` [GSoC Patch v3 4/4] repo: add path.gitdir " K Jayatheerth
2026-06-15 1:55 ` Lucas Seiki Oshiro
2026-06-15 1:59 ` [GSoC Patch v3 0/4] teach git repo info to handle path keys Lucas Seiki Oshiro
2026-06-15 4:51 ` [GSoC Patch v4 " K Jayatheerth
2026-06-15 4:51 ` [GSoC Patch v4 1/4] path: introduce append_formatted_path() for shared path formatting K Jayatheerth
2026-06-15 4:51 ` [GSoC Patch v4 2/4] rev-parse: use append_formatted_path() for " K Jayatheerth
2026-06-15 17:18 ` Justin Tobler
2026-06-16 4:19 ` K Jayatheerth
2026-06-15 4:51 ` [GSoC Patch v4 3/4] repo: add path.commondir with absolute and relative suffix formatting K Jayatheerth
2026-06-15 18:17 ` Justin Tobler
2026-06-15 4:51 ` [GSoC Patch v4 4/4] repo: add path.gitdir " K Jayatheerth
2026-06-16 4:49 ` [GSoC Patch v5 0/4] teach git repo info to handle path keys K Jayatheerth
2026-06-16 4:49 ` [GSoC Patch v5 1/4] path: introduce append_formatted_path() for shared path formatting K Jayatheerth
2026-06-16 13:08 ` Phillip Wood
2026-06-16 4:49 ` [GSoC Patch v5 2/4] rev-parse: use append_formatted_path() for " K Jayatheerth
2026-06-16 13:08 ` Phillip Wood
2026-06-16 17:04 ` K Jayatheerth
2026-06-16 18:26 ` Phillip Wood
2026-06-16 4:49 ` [GSoC Patch v5 3/4] repo: add path.commondir with absolute and relative suffix formatting K Jayatheerth
2026-06-16 4:49 ` [GSoC Patch v5 4/4] repo: add path.gitdir " K Jayatheerth
2026-06-20 3:16 ` [GSoC Patch v6 0/4] teach git repo info to handle path keys K Jayatheerth
2026-06-20 3:16 ` [GSoC Patch v6 1/4] path: introduce append_formatted_path() for shared path formatting K Jayatheerth
2026-06-20 14:27 ` Junio C Hamano [this message]
2026-06-20 16:30 ` K Jayatheerth
2026-06-20 3:16 ` [GSoC Patch v6 2/4] rev-parse: use append_formatted_path() for " K Jayatheerth
2026-06-20 3:16 ` [GSoC Patch v6 3/4] repo: add path.commondir with absolute and relative suffix formatting K Jayatheerth
2026-06-20 3:16 ` [GSoC Patch v6 4/4] repo: add path.gitdir " K Jayatheerth
2026-06-21 5:55 ` [GSoC Patch v7 0/3] teach git repo info to handle path keys K Jayatheerth
2026-06-21 5:55 ` [GSoC Patch v7 1/3] path: extract append_formatted_path() and use in rev-parse K Jayatheerth
2026-06-21 5:55 ` [GSoC Patch v7 2/3] repo: add path.commondir with absolute and relative suffix formatting K Jayatheerth
2026-06-21 5:55 ` [GSoC Patch v7 3/3] repo: add path.gitdir " K Jayatheerth
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=xmqqbjd5guci.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=a3205153416@gmail.com \
--cc=git@vger.kernel.org \
--cc=jayatheerthkulkarni2005@gmail.com \
--cc=jltobler@gmail.com \
--cc=kristofferhaugsbakk@fastmail.com \
--cc=kumarayushjha123@gmail.com \
--cc=lucasseikioshiro@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=sandals@crustytoothpaste.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