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

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.