Re: [GSoC RFC PATCH v3 0/5] repo-info: add new command for retrieving repository info
- From
Lucas Seiki Oshiro <lucasseikioshiro@gmail.com>
- Date
- Jul 11, 2025, 17:13 UTC
- Message-ID
- <0FEC4502-867F-4B9C-B752-376EF9464983@gmail.com>
- In-Reply-To
- <20250706231938.16113-1-lucasseikioshiro@gmail.com>
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