On 2023-10-28 04:52, Jacob Stopak wrote:
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?
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.
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.
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...
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.
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.
It looks like a logical choice to me.
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.
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.
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. :)
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.
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"...
Maybe "core.verbose"? We already have "core.pager", which kind of
affects the way all command outputs look like.
