On 2023-10-27 19:13, Jacob Stopak wrote:
On Fri, Oct 27, 2023 at 03:32:40PM +0200, Dragan Simic wrote:
On 2023-10-27 00:46, Jacob Stopak wrote:
> Take into account reviewer feedback by doing several things differently:
>
> * Rename this feature (for now) as "noob format mode" (or just "noob
> mode") instead of the original "--table" verbiage. As pointed out,
> this no longer ties the name of the setting to it's proposed
> implementation detail as a table. Noob mode is not necessarily the
> right name, just a placeholder for now. Unless people like it :D
>
> * Instead of manually having to invoke the -t, --table every time this
> format is to be used, set the config option "status.noob" to true.
> Although this is logically tied to the status command, there are
> many
> commands that produce status output, (and this series adds more), so
> assume that if the user wants to see the status this way, that it
> should be enabled whenever the status info is displayed.
How would "status.noob" relate to and coexist with possible future
configuration options named "<command>.verbose", which would be
somewhat
similar to the currently existing "commit.verbose" option? IOW,
perhaps it
would be better to have per-command options "<command>.verbose = noob"
or,
even better, "<command>.verbose = extended", to make it all more
future-proof and more granular.
Hmm, do there currently exist other <command>.verbose config settings
besides for commit? From what I can tell from "git help config", the
commit.verbose setting is the only one I see, and it just adds the diff
info into the editor if the user runs git commit without the -m flag,
but
otherwise there seems to be no extra verbosity outputted.
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.
I noticed that git add and git mv have "verbose" (-v, --verbose) cli
flags
which just output the name of the file being added or renamed, and that
certain other commands like git branch has a verbose output which
includes
the branch head commit hash and message in the output, so I guess this
one
is actually kindof verbose in that it outputs more than the non-empty
default output.
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.
So it seems like currently "verbose" is used for various things among
the
command set, sometimes meaning "add something into the template if one
is
used" or "add some tiny output to a command that has no default output"
(which still seems more "--shy" than "--verbose" :P) or "add some
additional output to a command that already has some sparse output".
Yes, that's the basic verbosity, as I named it above.
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.
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.