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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux