> Phillip Wood <phillip.wood123@gmail.com> 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.

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