Subject: Re: [GSoC RFC PATCH v2 0/7] repo-info: add new command for retrieving repository info

From: [email-masked]
Date: Wed, 2 Jul 2025 10:10:08 +0100

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