Re: [GSoC Patch v8 1/3] path: extract format_path() and use in rev-parse
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 24, 2026, 18:15 UTC
- Message-ID
- <xmqqy0g3iz38.fsf@gitster.g>
- In-Reply-To
- <20260624033748.108281-2-jayatheerthkulkarni2005@gmail.com>
K Jayatheerth <jayatheerthkulkarni2005@gmail.com> writes:
Show 40 quoted lines
> +void format_path(struct strbuf *dest, const char *path,
> + const char *prefix, enum path_format format)
> +{
> + strbuf_reset(dest);
> +
> + switch (format) {
> + case PATH_FORMAT_UNMODIFIED:
> + strbuf_addstr(dest, path);
> + break;
> +
> + case PATH_FORMAT_RELATIVE: {
> ...
> + 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: {
> ...
> + strbuf_addstr(dest, relative_path(path, prefix, &relative_buf));
> + strbuf_release(&relative_buf);
> + break;
> + }
> +
> + case PATH_FORMAT_CANONICAL:
> + /*
> + * strbuf_realpath_forgiving inherently resets the destination
> + * buffer, safely aligning with our replace semantics.
> + */
> + strbuf_realpath_forgiving(dest, path, 1);
> + break;
> +
> + default:
> + BUG("unknown path_format value %d", format);
> + }
> +}Hmph.
I was hoping that we could lose even more strbuf, but since relative_path() does not always leave its result in the strbuf that is passed to it as its third parameter, we do need addstr() into dest, which is a bit unsatisfying but not a fault of this patch at all. At least, we lost extra copy in the canonical codepath ;-)
Looking good. Thanks.