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

From: Jacob Stopak <jacob@initialcommit.io>
Date: Oct 22, 2023, 05:52 UTC
Message-ID: <ZTS4jfsU6oS6LW0u.jacob@initialcommit.io>
In-Reply-To: <d3bbe53c3b910f891c80465ea0c3f53f@manjaro.org>

Show 10 quoted lines

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

Interesting categorization I didn't think of splitting users that way. I guess for group 1 that's true, if they are shown a GUI and can run 3 commands that can do what they need, that's all they will ever use.

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

This is the exact way I learned Git and became comfortable and eventually confident using it. Reflecting on that, I really only started to become truly confident after understanding the core underlying concepts (maybe this is obvious / true for anything). And it's always easy once you get it.

However, there is one main benefit of a feature like this, that none of the other options (man pages, stack exchange, a textbook) can provide:

Since the tool (Git) has access to and knows the exact state of your local environment, it can provide instant feedback that takes into account that context. That is immeasurably more helpful than trying to figure out how to best ask Google your question, and then piecing together your problem with a similar one some lost soul ran into 10 years ago.

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

The default hints are an intersting consideration. I've found them handy for commands that I use infrequently, and also when I find myself in a scenario that is not a part of my usual workflow.

And the hint feature does show that Git has some "helper" features to hold the user's hand at least a little bit.

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

Somehow I do feel some sense of satisfaction at the countless times I've I've been stuck on some menial issue only to find out it had a stupid solution I overlooked. It's also just kind of funny in hindsight.

Regardless of a table formatting feature in Git, there is still plenty of sweet sweet pain to be had with software dev in general.

But in the moment I always do appreciate being able to get past a roadblock as quickly as possible. I would want a tool I design to be known for avoiding pain rather than causing it.

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

Even if the hints are off (presumably because the user felt confident enough or annoyed enough to turn them off), sometimes people just run into a situation they need an extra bit of clarification on.