Dragan Simic <dsimic@xxxxxxxxxxx> writes:
> IMHO, it would be the best to simply implement support for
> "<command>.verbose = table" in the git configuration, similarly to how
> we already have "commit.verbose = true". That way tables could be
> enabled per command, according to the user's preferences, regardless
> of performing dry runs or not.
I think the "use more verbose report format to help relatively
inexperienced folks, in exchange for spending more screen real
estate" is a good direction to think about this thing.
I am not personally interested in adding such support all that much
myself, but one piece of advice I can offer those who are interested
is not to be too deeply attached to the word "table".
It may be that "git status" (not "status -s" [*] but the current
version for human consumption) shows "paths with changes to be
committed (i.e. changes added to the index exist)" and "paths with
changes you could add to the index (i.e. changes yet to be added to
the index exist)" in a separate list, and Jacob may have found that
it gives a more understandable view into the states of each path if
the output is turned 90-degrees and the changes are shown in a
tabular form. But "table" in this example is merely an
implementation detail of one presentation that is easier to
understand for "git status", and calling it "table" and making it a
word in the vocabulary of <command>.verbose is like a tail wagging
the dog. We want to convey to the users that the option is about
"with extra verbosity, the user is buying a bit more clarity", not
necessarily "use tabular form no matter what".
For some of the commands, tabular presentation might not even be the
presentation form that is the easiest to understand to novices. For
example, I just pushed out today's integration result to some of my
repositories, and "git push" output looks like so:
To github.com:gitster/git.git
+ 5cb4030332...7dc6f5ada8 ak/color-decorate-symbols -> ak/colo...
+ a71066b71b...c80a646458 jch -> jch (forced update)
+ 89a1ffc6a4...416cdf7260 seen -> seen (forced update)
+ 7ff160463b...2c610ca9ff tb/merge-tree-write-pack -> tb/merge...
2e3b7b2460..57243409ad refs/notes/amlog -> refs/notes/amlog
This is already "tabular" and gives enough information to tell me
which ones did not get updated (e.g., I do not see 'next' there) and
which ones are forced ('jch' and 'seen' are usually forced and I'll
notice that I may have made mistakes if they are not). But a
hypothetical presentation that is easier for novices to read may
show "git log --oneline --graph old...new" (or some abbreviated form
of it) between the old and new tips of the affected branches. At
that point, calling the improved output as "table" would make little
sense.
For commands that Jacob found it easier to explain in tabular form,
like "git add", it is very possible that two years down the road,
another Jacob comes around and proposes a different presentation
that is even easier for novices to understand, and it may not be a
tabular form.
So be very careful when choosing what to call this new thing, and
avoid naming it after the implementation details (e.g., in what
particular shape the data gets presented) that may turn out not to
be the most important part of the concept.
[Footnote]
* FWIW, "git status -s" is a tabular presentation. Maybe we can
add a more verbose form of "-s" and be done with it for the
command?
