Re: [GSoC Patch v6 1/4] path: introduce append_formatted_path() for shared path formatting
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 20, 2026, 14:27 UTC
- Message-ID
- <xmqqbjd5guci.fsf@gitster.g>
- In-Reply-To
- <20260620031644.353772-2-jayatheerthkulkarni2005@gmail.com>
K Jayatheerth <jayatheerthkulkarni2005@gmail.com> writes:
Show 15 quoted lines
> 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?
Show 121 quoted lines
> 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"