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
