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
