On 2023-10-20 23:48, Jacob Stopak wrote:
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!
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.
* 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.
* 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.
* 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.
* 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.
