Re: [PATCH v4 02/10] repo: add path keys to repo info
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 27, 2026, 19:51 UTC
- Message-ID
- <xmqqldgeotgi.fsf@gitster.g>
- In-Reply-To
- <3c4d4909-4eb1-47f4-b601-8f877a07ddd5@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
Show 8 quoted lines
>> + { "path.common-dir", get_path_common_dir },
>> + { "path.config-file", get_path_config_file },
>> + { "path.git-dir", get_path_git_dir },
>> + { "path.git-prefix", get_path_git_prefix },
>
> I'm not sure about calling this 'git-prefix', 'prefix' might be more
> appropriate as it is about prefixing paths in the worktree rather than
> the git_dir.True.
Show 12 quoted lines
>> + { "path.grafts-file", get_path_grafts_file },
>> + { "path.hooks-directory", get_path_hooks_directory },
>> + { "path.index-file", get_path_index_file },
>> + { "path.logs-directory", get_path_logs_directory },
>
> We're moving away from file based refs and reflogs so I'm not sure
> adding this, pick-refs-file or refs-directory is a good idea as we
> should not be encouraging people to access these files directly.
>
>> + { "path.objects-directory", get_path_objects_directory },
>> + { "path.packed-refs-file", get_path_packed_refs_file },
>> + { "path.refs-directory", get_path_refs_directory },The same comment applies to these entries as well, as the pluggable object database support is just beyond the horizon if I understand correctly.
Show 6 quoted lines
>> + { "path.shallow-file", get_path_shallow_file },
>> + { "path.superproject-working-tree", get_path_superproject_working_tree },
>> + { "path.toplevel", get_path_toplevel },
>
> 'path.toplevel' matches the git-rev-parse option but 'path.work-tree'
> might be more descriptive?I think the "git repo" thrust comes primarily from being unfamiliar with "rev-parse" (and I wouldn't particularly encourage new people to become familiar with it---it grew pretty much organically driven by scripting needs without taking UI cleanliness into consideration very much), so not many folks would find it disturbing that "--toplevel" corresponds to "topOfTheWorkingTree". Given that we have a token to ask for superproject's working tree, giving a name made after the same phrasing philosophy for the current project's working tree would be a good thing, i.e., "path.working-tree".
> What happens if 'path.toplevel' is requested in a bare repository?
FWIW "git rev-parse --show-toplevel" dies with "must be run in a work tree". Better or worse,
rm -fr new git init new cd new/.git && git rev-parse --show-toplevel
also dies the same way, which I am not sure we want to inherit when we are making a new interrogator command.
Thanks.