Re: [RFC PATCH v2 0/6] Noobify format for status, add, restore
- From
Jacob Stopak <jacob@initialcommit.io>
- Date
- Oct 28, 2023, 15:21 UTC
- Message-ID
- <ZT0m68HWZS/tDGtH.jacob@initialcommit.io>
- In-Reply-To
- <2a0ba4c8e96cb7d2ea66dd1e78cdd39c@manjaro.org>
On Sat, Oct 28, 2023 at 07:55:31AM +0200, Dragan Simic wrote:
Show 6 quoted lines
> > So I assume an "add.verbose" config option would just always print that > > without having to specify the -v, --verbose flag when running the > > command? > > Yes, that's how I see it. Setting "add.verbose" to "true", to be precise, > or to "basic", which I'll explain a bit further later in my response.
Ok, gotcha!
Show 6 quoted lines
> > Basically what I'm asking is if commands that already have a --verbose > > flag > > would just get a config setting that does the existing thing by default? > > Well, not by default. The default values would remain "false", so nothing > jumps out of nowhere.
Right, sorry, I worded that poorly.
> > > > So it seems like currently "verbose" is used for various things among > > > > the command set... > > > > > > Yes, that's the basic verbosity, as I named it above.
Ok.
Show 10 quoted lines
> > Would it make sense to try to define a more consistent type of output or > > format style for "verbosity" across different commands? As it stands it > > seems each command treats verbosity in its own way which makes it hard > > to interpret exactly what it will do each time... > > We'd have to follow the already established behavior of the commands, and > there are the man pages to describe what's going on with the verbosity for > each command. In other words, nothing would get changed, just some more > knobs would be added, for those who prefer to have the additional verbosity > enabled.
Ok I see.
Show 7 quoted lines
> > Ok so it sounds like you prefer to use "verbose" as the setting key? > > I guess at this point that might make more sense since commit.verbose > > already exists, and existing options could be packed into it like you > > said instead of just true or false. > > It looks like a logical choice to me. >
Ok.
Show 13 quoted lines
> > And then my thing here would just be called "command.verbose = > > extended"? > > Yes, that's what I propose. It also looks like a logical choice to me, and > it would leave space for some possible later changes to the > "<command>.verbose = extended" verbosity, without tying it to the tables. > We'd also leave some space that way for even maybe an additional level of > verbosity, be it "<command>.verbose = simple", "<command>.verbose = > graphical" or whatever. > > Perhaps this scheme should also support "<command>.verbose = basic", which > would be an alias for "<command>.verbose = true", for additional clarity. >
Sounds good!
Show 7 quoted lines
> > Perhaps it would also be good to nudge the newbies a bit by requesting them > to enable the extended verbosity for each command by hand. That way they > would both learn a bit about the way git configuration works, which they > ultimately can't escape from, and they would be excited to learn new git > commands. Or I at least hope so. :) >
Hehe ok, maybe there is room in some hints to notify users of the extended option...
Show 11 quoted lines
> > And it's true that some users might only want the extended (or any > > format) for specific commands. I think a happy medium then is to have > > the command-specific settings like you mention, plus one toplevel > > option that enables a specific type of output format among all commands > > (and overrides the command-specific settings), so that the user can > > choose which they prefer. > > That's something we can consider as an additional configuration option. > That way, users could also enable the basic verbosity for all commands, > which may also be usable. >
Cool!
Show 5 quoted lines
> > Any thoughts on what the section in the config for a more general > > setting like this might be named? > > Maybe "core.verbose"? We already have "core.pager", which kind of affects > the way all command outputs look like.
Ok! The idea of using "core" came to mind but I wasn't sure if that was more for lower-level settings or more general things.
Great. Thanks a lot for all the feedback. Let me doctor up the patch series to take these things into account and submit an RFC v3 :D