Hi Lucas On 01/07/2025 23:18, Lucas Seiki Oshiro wrote:
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.I can't see any downsides in this format. I'll use it in v3!
That's great
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
and all the paths that are adjusted by update_common_dir() as well.
What about adding them all to the `git repo-info` under the `path` category?
That means keeping a list of paths that are special cased in two separate places which means they'll almost certainly get out of sync at some point in the future. It also means that instead of querying a whole path of a hook the script author has to remember to look up the hooks path and then append the hook name to that which makes it more of a faff to use. Letting the user just query the path they are interested in is a much nicer interface and makes it much easier to deal with the paths that reside under $GIT_COMMON_DIR.
Currently, these are the fields that I plan to add: - git-dir - common-dir - toplevel-dir - superproject-working-tree
git-prefix would be useful as well I think. Thanks Phillip
