From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 27 Feb 2026 19:51:57 GMT
Subject: Re: [PATCH v4 02/10] repo: add path keys to repo info
Message-ID: <xmqqldgeotgi.fsf@gitster.g>
In-Reply-To: <3c4d4909-4eb1-47f4-b601-8f877a07ddd5@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

>> +	{ "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.

>> +	{ "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.

>> +	{ "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.