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

From: Ayush Jha <kumarayushjha123@gmail.com>
Date: Mar 3, 2026, 03:27 UTC
Message-ID: <CAFNBzOeDU3BGdZjP0edvcd6OZxrP0VgN=AHSYTFseoKdMdu70g@mail.gmail.com>
In-Reply-To: <B46AA932-28EF-4A2C-96B9-0F05D9641C1C@gmail.com>

Hi Lucas,

I completely agree that having --all dump three variants of every path (default, relative, absolute) would be far too noisy and defeat the purpose of a clean metadata dump.

My thought is that the path.absolute.* and path.relative.* keys could be treated as "virtual" or computed keys.

If a user runs --all, the command would only iterate over and print the base keys (e.g., path.toplevel, path.git-dir). The specific format variants would simply be hidden from the iteration list, much like how some APIs only return expensive or highly-specific fields if they are explicitly requested.

This way, --all stays perfectly clean and concise, but scripts that need mixed granular control can still invoke git repo info path.absolute.git-dir path.relative.toplevel in a single pass without relying on global state flags.

Do you think treating them as explicit-request-only fields strikes the right balance between a clean --all output and a stateless API?

On Mon, Mar 2, 2026 at 1:25 AM Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> wrote:

Show 21 quoted lines

>
>
> > Hi Lucas,
>
> Hi, Ayush!
>
> > Thanks for sharing this series — moving the path formatting logic into
> > path.c makes a lot of sense and avoids duplication with rev-parse.
>
> Yeah, but since git-repo-info was written as a better home for
> some features currently in git-rev-parse, now we can think in
> better solutions.
>
> > For example, something along the lines of:
> > path.toplevel
> > path.absolute.toplevel
> > path.relative.toplevel
>
> I also thought about that, but what would happen with --all?
> If --all returns both absolute and relative, then we would
> have the third solution.