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

From: Dragan Simic <dsimic@manjaro.org>
Date: Oct 20, 2023, 23:02 UTC
Message-ID: <d3bbe53c3b910f891c80465ea0c3f53f@manjaro.org>
In-Reply-To: <ZTL1wJIIK/5YWQK5.jacob@initialcommit.io>

On 2023-10-20 23:48, Jacob Stopak wrote:

Show 20 quoted lines

> On Fri, Oct 20, 2023 at 08:48:12PM +0200, Dragan Simic wrote:
>> On 2023-10-20 20:39, Jacob Stopak wrote:
>> > This is a proposal / proof-of-concept for a new table-based output
>> > format for the git status command, and for dry runs (-n) of the git add
>> > command. This could be extended to create visual dry runs for other
>> > other commands like rm, mv, restore, stash, commit, and clean.
>> 
>> Huh, please don't get me wrong, but based on the examples provided 
>> below, I
>> really think that's only wasted screen estate, providing little or no 
>> help
>> in understanding the performed operations.
>> 
>> I appreciate your effort, but IMHO it makes little sense from the 
>> usability
>> standpoint.
>> 
> Thanks for the quick (and honest ;) reply - I appreciate it and no 
> offense
> taken! But let me try to expand on my reasoning a bit.

Thank you!

Show 6 quoted lines

> I agree with you that Git users who are already comfortable with Git,
> the command-line, and their workflows would be unlikely to use this in
> their day to day work.
> 
> The main benefits of this format are for beginners and folks who
> are still learning Git to use it as needed:

Oh, I always do my best to put myself in the shoes of the targeted audience. Maybe I sometimes fail at that, I don't know, but that's why we're here to discuss it further.

Show 6 quoted lines

>   * To beginners, the concepts of working directory and "staging area"
>     can be very abstract. By representing these concepts as table 
> columns
>     on the screen, (a format that 99% of humans are used to 
> interpreting),
>     they become more tangible and intuitive to new users.

Frankly, based on my rather broad experience, there are two primary categories of the beginners in the world of version control software (VCS), be it git or any other product:

1) People who are forced to use some VCS at work, and they actually 
don't give a damn about it.
2) True enthusiasts who love what they do, and who love expanding their 
knowledge.

For the first category, nothing helps. For the second category, a nicely written tutorial is all they needed to start with, aided later with the man pages, Stack Exchange, and perhaps some textbook.

Show 13 quoted lines

>   * In Git, changes fly around all over the place, in all sorts of
>     directions. Even small hints at this movement can be very helpful 
> to
>     understand what the heck is going on. The table format (esp with
>     arrows used in the 'git add' version) highlights the "flow" of
>     changes through the workflow in a way that the current default 
> format
>     doesn't. The current dry runs just show the filenames being added
>     without context of _where_ they come from and where they are going.
>     Not to mention many commands don't even have dry runs. This might
>     sound like a small thing, but to a newbie having that extra level 
> of
>     confirmation and understanding can make a big difference.

Please don't get me wrong, I understand your reasoning, but again, it all comes down to the two categories described above. IMHO, the second category will likely start turning off the default hints sooner than turning the table formatting on. The first category will choose some GUI anyway.

Show 7 quoted lines

>   * Git doesn't exactly have a reputation as a user-friendly tool, and
>     much of that stems from the difficulty of learning Git. So we 
> should
>     try to make it more approachable to normal humans. This format
>     (esp if applied to a wide variety of commands as dry runs) would
>     provide a rudimentary visual output that is more intuitive to 
> users.

No pain, no gain. That's the ancient mantra, but IMHO it still applies very well to many things, and of course not to the first category mentioned above. Nothing applies to that category.

Show 6 quoted lines

>   * This flag doesn't change any default behavior, it can easily be
>     tossed on for newbie use (either when teaching a newbie or when the
>     newbie is practicing on their own). Given this usage, the screen
>     realestate is not really a concern. I.e. this would be used
>     specifically when needed for the extra info/clarity it provides,
>     not to be efficient with the terminal space.

As I already assumed above, the targeted audience will likely start turning the default hints off, rather than turning the table formatting on. Maybe I'm wrong there, who knows.

> That's my perspective anyway, but of course the point of this is to
> propose it to the community and hear the response, so even if it's
> not included it's still a good experience :D.

Let's hear more thoughts from other people, of course.