Hi Lucas

On 19/06/2025 23:57, Lucas Seiki Oshiro wrote:

Hi!

This is the second version of the repo-info RFC, and these are the main changes
introduced since v1:

- The plaintext format now returns its fields in a key=value format

I think that is a good idea. It also now quotes values that contain 
control characters. In my experience quoting paths works well when one 
is processing the output of one git command and feeding into the stdin 
of another git command. In cases where the script itself wants to use 
the path having to unquote them is a pain and it is much more convenient 
to to read NUL terminated input "lines" that are not quoted. I think the 
output from this command falls into that latter category and so I'm not 
convinced that a LF terminated output is particularly useful. I think 
using an output format generated by 'printf("%s\n%s\0", key, value)' 
would be easier to parse. This format matches that used by 'git config 
--list -z'.

As this is a plumbing command I think it would be clearer if the caller 
was required to specify the output format and the information that they 
require with an "--all" option for "show me everything" as Junio 
suggested. If we were to set defaults for the format and keys now we 
would be stuck with them forever.

I've not seen any discussion of how paths are going to be encoded in the 
JSON output. As I understand it some JSON decoders only accept utf8 
input but the paths reported by git are arbitrary NUL terminated byte 
sequences. How is one expected to parse the output for a non utf8 
encoded path using rust's JSON decoding for example?

On the subject of paths do you plan to support the equivalent of "git 
rev-parse --git-path"? That is very useful in scripts as the script 
author does not have to worry about the details of where exactly each 
file lives and for paths like "index" or "hooks" it takes the relevant 
environment variable or config setting into account. We should design 
the output format so that it can accommodate keys with the requested 
path. I think it would be reasonable to reject requests for paths 
containing newlines which would be compatible with the output format 
suggested above.

I'm not sure what the future plans for this command are but when I'm 
scripting around git it would be nice to be able to a single process 
that I could query for the things currently returned by "git rev-parse", 
"git var" and "git config"

Best Wishes

Phillip