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