Re: [RFC PATCH v2 0/6] Noobify format for status, add, restore

[Jacob Stopak <jacob@initialcommit.io>]

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