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

From: Jacob Stopak <[email-masked]>
Date: Fri, 27 Oct 2023 19:52:44 -0700

> They currently don't exist, but that's something I've planned to implement,
> e.g. to "add.verbose" as a new configuration option.  It should be usable,
> while not being messy or intrusive as a new feature.

"git add" already has the -v, --verbose flag available for the command
itself like:

$ git add -v foo.txt
add 'foo.txt'

But like you said the config option add.verbose doesn't seem to exist yet.

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?

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?

> Yes, those are the basic per-command verbosity modes or levels, as I call
> them.  The way I see it, your patches would add new, extended per-command
> verbosity levels.

Ok, I see.

> > 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.

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...

> > Another thing is that commands like status have multiple flags that can
> > be
> > used to specify the output format, such as --short, --long, --porcelain,
> > etc, but only --short seems to be configurable as a git config setting.
> > Is there a reason (besides backward compatibility I guess) that these
> > aren't rolled into a single thing like --format=<type>? This seems like
> > it would be the easiest way to future proof for new formats like
> > --format=verbose, --format=noob, --format=extended, etc.
> 
> That's a good question, but I'd need to go through the commit history to be
> able to provide some kind of an explanation.  It could also be all packed
> into "status.verbose" as a new configuration option.

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.

And then my thing here would just be called "command.verbose = extended"?

> > From a noob's perspective though, does adding a config setting for each
> > command really make sense? I'm kindof envisioning this setting now as a
> > "mode" that is either enabled for all commands it affects or for none.
> > And it's highly unlikely a newish user would individually discover which
> > commands this "extended" format is available for, and run "git config
> > <command>.verbose = extended" for every one. I mean we could do that
> > in case there are folks who only want it for specific commands, but to
> > fulfill it's purpose I think there should definetely be some general way
> > to enable the setting for all commands that have it.
> 
> Quite frankly, we shouldn't expect that all users are noobs, and as a result
> dumb everything down just to make them as comfortable as possible.  On the
> other hand, perhaps not everyone would like to have extended verbosity
> enabled for all commands, just as not everyone uses "-v" for all commands.

I agree with this, and I think it's important to cater to both newbies and
experienced users alike. That's why I said I never dreamed of making this
new format the default.

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.

Any thoughts on what the section in the config for a more general setting
like this might be named? If "status.verbose = extended" would already be
taken specifically for the status command, what terminology could we use
to mean something like "global.verbose = extended" or "global.extended =
true"? Although the former seems better to me since other format values
could be implemented, like "global.verbose = standard"...