Re: [GSoC Patch v8 0/7] repo: add path keys to repo info

[Phillip Wood <phillip.wood123@gmail.com>]

On 09/11/2026 16:52, K Jayatheerth wrote:
> On Sun, Nov 8, 2026 at 1:27 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
>>>
>>> The path keys added in this series are:
>>>     - `path.toplevel.absolute` / `path.toplevel.relative`: The root directory
>>>       of the working tree (or an empty string in bare repositories).
>>
>> In our documentation and glossary, we call this directory the "working
>> tree" so I think "path.working-tree.*" would be a better name, rather
>> than copying the name from the equivalent rev-parse option.
>>
>>>     - `path.superproject-root.absolute` / `path.superproject-root.relative`:
>>>       The root of the superproject when inside a submodule.
>>
>> Personally, I'd prefer "path.superproject-working-tree.*" here, though I
>> see Justin thought that was a bit of a mouthful. As this command is for
>> use in scripts I'd rather have a descriptive name.
>>
> 
> I don't have an opinion on the name itself, but, that said:
> I think superproject-working-tree is a more suiting name.
> It is becuase you may have a working tree in a different place and it
> might not be the root itself.
> I think the same logic applies for toplevel too.
> 
> Any more thoughts from Justin, Lucas, Junio or any other reviewer
> would be better I reckon.

Yes, that would be helpful

>>>     - `path.hooks.absolute` / `path.hooks.relative`: The repository's hooks
>>>       directory (respecting `core.hooksPath`, including `/dev/null`).
>>
>> Given we have config based hooks now, do we really want to add this?
>> Scripts that want to run hooks should be using "git hook run" and
>> scripts that want to install hooks should be using the config based
>> hooks so that they co-exist with the user's existing hooks.
>>
> 
> I believe that is a fair point for new tooling, though wouldn't many
> existing scripts
> and third-party tools still learn about hooks directly via `git
> rev-parse --git-path hooks`?
> 
> Since the main goal of `git repo info` is to provide an alternative
> to `rev-parse`'s various path flags, `path.hooks` still seems useful for scripts
> migrating over, unless the consensus is to deprecate querying the hooks
> directory altogether.

Isn't the goal to provide a better interface than rev-parse, rather than 
just porting the various path related options across unchanged? My worry 
is that by adding "path.hooks.*" we're encouraging people to use an 
outdated interface that ignores the existence of config based hooks. 
Anyone who wants to keep using "git rev-parse --git-path hooks" can do 
so, but I'd rather we didn't encourage that pattern by supporting it in 
new commands.
>>>     - `path.cdup`: The relative path from the current directory up to the
>>>       worktree root.
>>
>> How does this differ from path.working-tree.relative? I've never really
>> understood "git rev-parse --cdup" - if you're in the repository root
>> directory, 'cd "$(git rev-parse --cdup)"' dumps you in your home
>> directory which has always seemed a bit surprising to me.
>>
> 
> Well looking at the code itself
> What I can say is I find couple of edge cases,
> 
> The cdup command relies on a slash counting loop on the prefix string
> to output directory-up
> sequences like '../', returns an empty string at the root and falls
> back to the worktree path when outside.
> 
> On the contrary, relative formatting uses Git's path utility library
> to compute true relative
> filesystem paths, outputting '.' at the root instead of leaving it blank.

Right - but what practical benefit does "path.cdup" offer over 
"path.working-tree.relative"? "git rev-parse --cdup" was added in 
5f94c730f3 (rev-parse: --show-cdup, 2005-12-22), four years before 
"--show-toplevel" in 7cceca5ccc (Add 'git rev-parse --show-toplevel' 
option., 2010-01-12) and 15 years before support for relative paths in 
fac60b8925 (rev-parse: add option for absolute or relative path 
formatting, 2020-12-13). So when it was added "--cdup" was the only way 
to find the root of the repository working tree, which is not the case now.

Thanks

Phillip