> The reason git uses NUL termination for other commands is to prevent breaking the output when values contain newlines. The output format I'm suggesting is > > <key><LF><value><NUL> > > so the output for "path.git-dir" written as a C string would be > > "path.git-dir\n/home/phil/src/git/.git\0" > > The value can safely contain newlines because it is terminated by '\0'. The reason that "git config --list -z" exists is to provide an unambiguous output format as config values can contain newlines. OK! I can't see any downsides in this format. I'll use it in v3! > If this command is going to return "$GIT_DIR" and "$GIT_WORK_TREE" then I don't see why it should not be able to provide other paths. Hmmm... I never used `git rev-parse --git-path`, but after inspecting it, it seems to have special cases for: - grafts file - index file - objects directory - hooks directory What about adding them all to the `git repo-info` under the `path` category? Currently, these are the fields that I plan to add: - git-dir - common-dir - toplevel-dir - superproject-working-tree > Those combined with "git var" and "git config" are all repository settings. Having a unified interface to them would be an improvement on the status quo where users have to know which command to call to query different settings. Fair! By now, I'm focusing on rev-parse, but it seems to make sense. > Best Wishes Thanks again for your extensive review!
