Subject: Re: [PATCH v4 02/10] repo: add path keys to repo info

From: Phillip Wood <[email-masked]>
Date: Sun, 1 Mar 2026 10:36:52 +0000

On 27/02/2026 19:51, Junio C Hamano wrote:
> Phillip Wood <[email-masked]> writes:
> 
>>> +	{ "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.

Good point. Also what is the "shallow file" below and should scripts be 
poking it directly?

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

That's a good idea

>> 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.

Yes, I think printing an empty value after the key would be better - I 
don't think there are any paths where we care about the distinction 
between NULL and ""

Thanks

Phillip