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

From: Lucas Seiki Oshiro <[email-masked]>
Date: Fri, 11 Jul 2025 14:13:31 -0300

Hello again!

I just had a meeting with Justin, especially focused on joining this `repo-info`
command and his `survey` command [1] under the same command (perhaps called 
`git repo`).

Some highlights of our discussion:

1. How would this integration be done? Making this `git repo` command only as a
   house for two different subcommands, or making it a common interface for our
   work. An argument for separated subcommands is that `repo-info` is a light
   command, while `survey` is more computationally expensive. An argument for
   having a common interface is having a standard format for requesting and
   retrieving data from both sources.

2. A solution for 1. would be keeping the idea of having `repo-info` and
   `survey` as two subcommands (perhaps `git repo info` and `git repo stats`),
   following the same output format. This would also make room for a third
   command which would return data from both commands. Then `git repo` would be
   a plumbing command (`git survey` is more porcelain-ish), and its machinery
   could be used by a separate porcelain command for formatting its output in a
   more human-readable way.

3. Justin asked me about "why JSON?". And yeah, to be honest I'm using JSON
   because it was listed in the GSoC idea of a machine-readable format that could
   be easily parsed by other applications. Given that this would be (as far as I
   remember) the only git command that outputs JSON, it would be out of place,
   while the other format (null-terminated) is easier to manipulate (e.g. JSON
   has Unicode issues mentioned by Phillip) and follows an already used syntax
   (the same as `git config --list -z`). This way, it seems to me that dropping
   JSON is the way to go.

To sum up, we'll end with a `git repo` command with two (or three) subcommands
that output their data in the same format (the null-terminated format).

Then, you can skip reviewing this v3. Instead, I would like to ask you for
comments about this new direction.

Thanks!

[1] https://gitlab.com/gitlab-org/git/-/issues/529#note_2585264408