On Sat, Oct 28, 2023 at 07:55:31AM +0200, Dragan Simic wrote: > > 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! > > 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. > > 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. > > 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. > > 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! > > 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... > > 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! > > 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
