On Fri, Jul 04, 2025 at 06:40:11PM -0300, Lucas Seiki Oshiro wrote: > > > One thing I wondered: Justin is currently iterating on git-survey(1), > > which is the command Stolee proposed a while ago to gather repository > > metrics. > > I didn't find it in the mailing list, but I remember seeing it in the > the GitLab's fork. Is it this unmerged MR? > https://gitlab.com/gitlab-org/git/-/merge_requests/369 Yup. It's been posted to the mailing list as part of [1]. > > Would it make sense to maybe have such whole-repo commands > > grouped together in a `git repo` top-level command? E.g. `git repo info` > > for your command, `git repo size` to gather information about the repo > > size. > > It seems to be very nice for me! In fact, this being a home also for > statistics is something I considered while writing the first versions of > my GSoC proposal. > > And what about merging the two codes into a single API? Something like: > > ``` > git repo-info layout.bare references.format survey.commit-count > { > "layout": { > "bare": true > }, > "references": { > "format": "files" > }, > "survey": { > "commit-count": 42 > } > } > > ? We could in theory do that. But there's two things we need to be cautious about: 1. We should be mindful about what specifically this tool is about. It shouldn't become the next tool that does way too many different things. 2. One of the idea of git-survey(1) is to eventually replace git-sizer(1). This will require very specific presentation formats that aren't really compatible with any of the other information. Out of these two I think the second item is the more important one why git-survey(1) should exist as a standalone tool, either as a top-level command or as a subcommand. > During our meetings, Karthik suggested (I'm planning to it later) to also > allow to request an entire category instead of only the fields. Then, this > would also be possible: > > ``` > $ git repo-info survey > { > "survey": { > "commit-count": 42, > "blob-count": 1234 > } > ``` It raises another question though: if we ever were to add `--all` we'll need to step a bit careful about what kind of information we add to this tool. All of the information proposed so far can be computed rather trivially. But computing repository sizes has way higher computational complexity and may easily take seconds, maybe even minutes in large repositories. That to me further points into the direction of giving those two tools a common top-level command (`git repo info`, `git repo survey`), but to not mix concerns too much with one another. > But I don't know what are Justin's plans for git-survey, if it would be a > porcelain command for showing those stats to the user of if it is targeted > for being parsed like this `repo-info`. > > I'm just brainstorming because I liked the idea :-) I've already pinged him on this and he liked the idea of having a common top-level command. I guess he'll respond later today or this week. Patrick
