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

From: JAYATHEERTH K <jayatheerthkulkarni2005@gmail.com>
Date: Mar 1, 2026, 06:50 UTC
Message-ID: <CA+rGoLcGB-iJX7U16NmONr_EhYLnsn0eNAAdcdExRLQtMv732w@mail.gmail.com>
In-Reply-To: <CAFNBzOdCx=R3r9+m5eDyAykMAbmbcfpX3kPeEPjqXPYT-_89+g@mail.gmail.com>

Hi Ayush,

On Sun, Mar 1, 2026 at 11:15 AM Ayush Jha <kumarayushjha123@gmail.com> wrote:

Show 21 quoted lines

>
> Hi Lucas,
>
> Thanks for sharing this series — moving the path formatting logic into
> path.c makes a lot of sense and avoids duplication with rev-parse.
>
> Regarding the limitation you mentioned about not being able to mix
> relative and absolute paths within the same invocation, I was
> wondering whether it might be worth considering making the path format
> part of the key itself, rather than controlled by a global flag.
>
> For example, something along the lines of:
> path.toplevel
> path.absolute.toplevel
> path.relative.toplevel
>
> This could allow users to request different formats in a single call
> without introducing global state into the command output.
> That said, I’m not sure whether this would complicate the key
> namespace too much, or whether maintaining parity with rev-parse
> semantics is preferable for consistency.

I think this idea works for individual retrieval It still won't work when the request is for --all The main problem of absolute vs relative would arrive from the --all perspective, no?

If a script specifically needs both formats for a set of paths, the caller can easily just invoke the command twice: i.e git repo info --path-format=absolute <keys...> git repo info --path-format=relative <keys...>

It would still work for individual path terms

I think adding the absolute or relative terms in key is more of a "user" friendly one.

What do you think about it?

Regards,
- Jayatheerth