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

From: Junio C Hamano <[email-masked]>
Date: Sun, 01 Mar 2026 22:42:42 -0800

Phillip Wood <[email-masked]> writes:

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

If the new and safer variant of the command should signal "error" by
giving an empty string, it would work with its "--show-toplevel"
equivalent run in a bare repository.  In a working tree, it would
give a full/absolute path, and never be an empty string.  I am still
unsure what that new and safer one should do from inside the .git
directory.  "rev-parse --show-toplevel" dies.  $(cd .. && pwd) may
be another plausible and arguably more useful answer.

Your idea of equiating NULL and "", I do not think it would work
well with "git rev-parse --show-cdup" equivalent.  The command will
give us an empty string from the top-level of the working tree.

Curiously, in this sequence

	rm -fr new
	git init new
	cd new/.git && git rev-parse --show-cdup
	cd objects && git rev-parse --show-cdup

two "rev-parse" do not die with "must be run in a work tree", and
worse yet, they do not give you ".." or "../../", either.

It seems that one rule of "rev-parse --show-<some-path>" is that
"when you are inside .git directory of a non-bare repository, we'd
behave as if you are in a bare repository as if its working tree
does not exist", and the above is consistent with that rule.
"--show-cdup" does not fail but gives an empty string when run
anywhere in a bare repository.

But among "rev-parse --show-<anything>" that are about working tree
paths, there seems no unifying rule on what to do when in a bare
repsitory.  As we already saw, "--show-toplevel" dies without a
working tree.  This reflects the history of rev-parse that grew
organizally without a grand design.

If we are adding new and safer interface to these pieces of
information to "repo info", we may want to straighten these rules.