Re: [PATCH 0/4] repo: add support for path-related fields

From: JAYATHEERTH K <jayatheerthkulkarni2005@gmail.com>
Date: Mar 3, 2026, 07:23 UTC
Message-ID: <CA+rGoLc+ULYUZaDCdAHxuL8T-qyjJKTRJfSe6Muhb7c6d12e_w@mail.gmail.com>
In-Reply-To: <108ccc9d-5777-4c84-9dad-c2d0f5dc2e42@gmail.com>

On Tue, Mar 3, 2026 at 10:02 AM Tian Yuchen <a3205153416@gmail.com> wrote:

>
> Hi JAYATHEERTH,

Hi Tian,

Show 11 quoted lines

>
> > I see your point here.
> > but wouldn't this effectively be the same as Ayush's suggestion, just
> > with a different syntax?
>
> In my view, this issue is actually to choose the most suitable tool for
> the job. After all, we don't want to use something like rev-parse, which
> is riddled with *ancient* technical debt, nor do we want to write an
> even more verbose parsing function from scratch for what you call
> verbose user input, right?
>

I agree that it provides a clean and scalable mechanism, especially in terms of extensibility and per-field formatting without relying on global flags.

To clarify my earlier comment: I wasn't arguing against ref-filter. In fact, I’m more inclined toward using the best tool for the job. My earlier point was mainly about behavioral similarity and how both belong to the same camp even though they might seem different.

Show 20 quoted lines

> If I'm not mistaken, using different parsing functions to parse input is
> absolutely not just a matter of syntax differences. Instead, this will
> directly result in differences in data structures.
>
> The reason I recommend this approach is because its implementation is
> incredibly clear and concise. To achieve the functionality we desire,
> all we need to do is add the following to the registry:
>
> [ATOM_PATH] = { "path", SOURCE_NONE, FIELD_STR, path_atom_parser }
>
> And the corresponding path_atom_parser().
>
> This approach also offers strong scalability: If one day I decide to add
> a new feature like %(path:commondir,relative) output, all it would take
> is adding a switch statement in the parser() function (along with a few
> other minor tweaks).
>
> *I'm not saying this approach is better than the solution you've
> discussed. I'm simply presenting a possible implementation for
> reference. (´～`)

That is a detailed mail, thanks for taking time

When I said similar I meant

something like this:

static const struct repo_info_field repo_info_field[] = {
    { "layout.bare", get_layout_bare },
    { "layout.shallow", get_layout_shallow },
    { "object.format", get_object_format },
    { "path.toplevel", get_path_toplevel },
};

This array contains all the keys You do not need to hardcode path.absolute.toplevel, path.relative.toplevel, etc., in the array...

Instead,

If the user asks for path.absolute.toplevel: You detect the absolute. middle part. strip it out to find the base key path.toplevel. You find path.toplevel in the aray, the array works with default values when entered --all

/*
 * Helper to parse the key variant.
 * Takes "path.absolute.git-dir" -> returns "path.git-dir" and sets
opts->format.
 */
static char *normalize_key(const char *raw_key, struct repo_info_opts *opts)
{
    const char *suffix;

    /* Check for "path.absolute." prefix */
    if (skip_prefix(raw_key, "path.absolute.", &suffix)) {
        opts->path_format = PATH_FORMAT_ABSOLUTE;
        return xstrfmt("path.%s", suffix);
    }

    /* Check for "path.relative." prefix */
    if (skip_prefix(raw_key, "path.relative.", &suffix)) {
        opts->path_format = PATH_FORMAT_RELATIVE;
        return xstrfmt("path.%s", suffix);
    }

    /* No variant found, return raw key as-is */
    return xstrdup(raw_key);
}

Structurally, this mimics the ref-filter parsing phase almost exactly. Just as ref-filter splits a compound atom like %(refname:short) into an identity (refname) and a modifier (short) to populate the handler's state, normalize_key splits path.absolute.git-dir into the identity (path.git-dir) and the modifier (absolute).

I just meant both the ideas are in the same camp just unrealized.

What do you think?

Regards
- Jayatheerth