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.
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:
* 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.
* 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.
* 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.
* 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.
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.
