Re: [RFC PATCH 0/5] Introduce -t, --table for status/add commands

Dragan Simic <dsimic@manjaro.org> writes:

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?