On 25/07/17 03:03PM, Patrick Steinhardt wrote: > On Wed, Jul 16, 2025 at 09:04:40AM -0500, Justin Tobler wrote: > > If we already plan to support additional output formats, they I agree we > > should probably a `--format=<output-type>` flag from the start. I still > > think it would be nice to have a `-z` flag that is shorthand for > > `--format=nul` though as that is fairly common across other commands to > > have such an option. > > > > Out of curiousity, is there a reason we are interested in supporting a > > JSON output format in addition to what is already proposed? From an > > earlier conversation I had with Lucas, it didn't seem like there was any > > particular reason for JSON. > > I don't care much about the JSON output format. What I do care about is > to have a default format that we are free to iterate on, especially in > the context of `git repo size`. If we ever want to have output that is > as user friendly as git-sizer(1)'s we need to have that freedom. > > From my perspective that necessitates two things: > > - That we are able to change formats with a proper `--format=` flag. > `-z` alone doesn't fit that bill, as we are already talking about > there formats: user friendly, key-value pairs, and key-value pairs > with NUL termination. > > That being said I'm not opposed to also have `-z` as an alias as > long as we also have `--format=`. > > - That the _default_ format is the user friendly format that we can > iterate on, at least for `git repo size`. Otherwise we have already > failed on our mission to supply a user-friendly alternative to > git-sizer(1). I was originally of the mindset that git-repo(1) would focus on being more of a plumbing commmand and if we wanted to provide a more user-friendly decorated format for something akin to git-sizer(1) info, that would be better done through a separate command. Thinking about this some more though, I agree with you that we should probably just have git-repo(1) be the single stop and provide the various output flavors for its subcommands. If this is the route we go down, the default mode should be user-friendly. I think a key attribute of this user-friendly mode is that it should be free to change and be iterated on. If a user wants a stable output format, they should request the key-value output form that is line/nul-delimited. So maybe we have three different output modes for `--format=<mode>`: `user` (default), `keyvalue`, and `nul`? For `git repo info`, I'm not entirely certain how the default user-friendly mode would/should differ from the key-value one, but maybe that is not something we need to worry about right now. For now, the two modes could match and over time update the user mode as desired. -Justin
