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

From: Ayush Jha <kumarayushjha123@gmail.com>
Date: Mar 1, 2026, 05:45 UTC
Message-ID: <CAFNBzOdCx=R3r9+m5eDyAykMAbmbcfpX3kPeEPjqXPYT-_89+g@mail.gmail.com>
In-Reply-To: <CA+rGoLdTc2caDUsQedpegL+T4MqwwiA62uuDSFSawAT5vcPvWQ@mail.gmail.com>

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’d be interested to hear your thoughts on this trade-off.

Best, Ayush

On Sun, Mar 1, 2026 at 8:28 AM JAYATHEERTH K <jayatheerthkulkarni2005@gmail.com> wrote:

Show 63 quoted lines

>
> On Sun, Mar 1, 2026 at 4:14 AM Lucas Seiki Oshiro
> <lucasseikioshiro@gmail.com> wrote:
> >
> > Hi!
> >
>
> Hey Lucas,
>
> > This patch series adds support for path-related fields in repo-info, based on
> > what we already have in git-rev-parse:
> >
> > 1. The two first patches moves the path formatting used by git-rev-parse to
> >    path.c. This will allow us to reuse this code in git-repo-info
> > 2. The second patch add a new flag --path-format to git-repo-info, similar to
> >    the flag of git-rev-parse with the same name
> > 3. Add the new field `path.toplevel` as a proof of concept.
> >
> > This arises from the fact that I didn't know what should be the default behavior
> > of git-repo-info when dealing with paths. Some ideas were:
> >
> > 1. Add --path-format, just like we have in git-rev-parse
> > 2. Use what rev-parse uses by default
> > 3. Add keys for both relative and absolute formats
> >
> > In this case, I'm using 1, but I'm not sure if it's the best option. One
> > downside that I see here is that git-repo-info won't be able to return
> > a relative and an absolute path for different keys in the same call.
> >
>
> Option 1 feels like the cleanest approach.
> Even though it means git-repo-info can't return both a relative and
> absolute path in the exact same call, it keeps the API highly predictable
> for scripting without bloating the key namespace (which Option 3 would do).
>
> The behaviour is different when compared to the command itself where we
> have to use --all, but I think in this area this is the right approach.
>
> > Since there are many people interested in contributing to git-repo-info, I'll
> > leave the remaining path-related fields to them :-)
> >
>
> Thank you ;)
>
> > I'm CC'ing here:
> >
> > - brian, who was the original author of the `print_path` [1]
> > - Ayush, Tian, Jayatheerth, Soutrik and Pushkar, since they expressed interested
> >   in contributing to git-repo-info in GSoC. (I hope that I didn't forget anyone)
> >
> > This patch is based on top of master 2cc7191751 (The 8th batch, 2026-02-27) with
> > lo/repo-leftover-bits merged.
>
>
> This provides a fantastic foundation.
> I have updated my GSoC proposal based on these patches to build out
> the remaining path.* keys, alongside category-based querying and
> global state removal.
>
> I will be sending that in a completely new thread shortly.
>
> Regards
> - Jayatheerth