From: Ayush Jha Date: Tue, 03 Mar 2026 03:27:38 GMT Subject: Re: [PATCH 0/4] repo: add support for path-related fields Message-ID: In-Reply-To: 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 wrote: > > > > 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.