From: Jacob Stopak <jacob@initialcommit.io>
To: Dragan Simic <dsimic@manjaro.org>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH 0/5] Introduce -t, --table for status/add commands
Date: Sat, 21 Oct 2023 22:52:13 -0700 [thread overview]
Message-ID: <ZTS4jfsU6oS6LW0u.jacob@initialcommit.io> (raw)
In-Reply-To: <d3bbe53c3b910f891c80465ea0c3f53f@manjaro.org>
> 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.
next prev parent reply other threads:[~2023-10-22 5:52 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-20 18:39 [RFC PATCH 0/5] Introduce -t, --table for status/add commands Jacob Stopak
2023-10-20 18:39 ` [RFC PATCH 1/5] status: introduce -t, --table flag Jacob Stopak
2023-10-20 18:39 ` [RFC PATCH 2/5] status: handle long paths with " Jacob Stopak
2023-10-20 18:39 ` [RFC PATCH 3/5] status: add advice arg for " Jacob Stopak
2023-10-20 18:39 ` [RFC PATCH 4/5] add: add -t, --table flag for visual dry runs Jacob Stopak
2023-10-20 18:39 ` [RFC PATCH 5/5] add: set unique color for -t, --table arrows Jacob Stopak
2023-10-20 18:48 ` [RFC PATCH 0/5] Introduce -t, --table for status/add commands Dragan Simic
2023-10-20 21:48 ` Jacob Stopak
2023-10-20 23:02 ` Dragan Simic
2023-10-20 23:28 ` Junio C Hamano
2023-10-22 6:04 ` Jacob Stopak
2023-10-22 6:52 ` Dragan Simic
2023-10-22 5:52 ` Jacob Stopak [this message]
2023-10-22 6:38 ` Dragan Simic
2023-10-22 10:30 ` Oswald Buddenhagen
2023-10-22 12:55 ` Dragan Simic
2023-10-23 10:52 ` Oswald Buddenhagen
2023-10-23 14:34 ` Dragan Simic
2023-10-23 17:30 ` Jacob Stopak
2023-10-23 17:59 ` Dragan Simic
2023-10-23 18:16 ` Oswald Buddenhagen
2023-10-23 19:29 ` Jacob Stopak
2023-10-23 20:19 ` Oswald Buddenhagen
2023-10-23 20:51 ` Dragan Simic
2023-10-23 21:14 ` Oswald Buddenhagen
2023-10-23 21:19 ` Dragan Simic
2023-10-23 23:17 ` Jacob Stopak
2023-10-24 1:10 ` Dragan Simic
2023-10-24 2:03 ` Junio C Hamano
2023-10-24 2:21 ` Dragan Simic
2024-01-05 19:14 ` Dragan Simic
2024-01-06 4:44 ` Jacob Stopak
2024-01-06 7:06 ` Dragan Simic
2023-10-23 20:29 ` Dragan Simic
2023-10-23 19:01 ` Junio C Hamano
2023-10-23 19:04 ` Dragan Simic
2023-10-23 20:47 ` Oswald Buddenhagen
2023-10-23 20:59 ` Dragan Simic
2023-10-23 21:23 ` Jacob Stopak
2023-10-23 21:26 ` Dragan Simic
2023-10-23 21:12 ` Jacob Stopak
2023-10-22 15:50 ` Jacob Stopak
2023-10-26 22:46 ` [RFC PATCH v2 0/6] Noobify format for status, add, restore Jacob Stopak
2023-10-26 22:46 ` [RFC PATCH v2 1/6] status: add noob format from status.noob config Jacob Stopak
2023-10-30 1:32 ` Junio C Hamano
2023-10-30 1:38 ` Dragan Simic
2023-10-30 6:06 ` Jacob Stopak
2023-10-26 22:46 ` [RFC PATCH v2 2/6] status: handle long paths in noob format Jacob Stopak
2023-10-26 22:46 ` [RFC PATCH v2 3/6] add: implement noob mode Jacob Stopak
2023-10-26 22:46 ` [RFC PATCH v2 4/6] add: set unique color for noob mode arrows Jacob Stopak
2023-10-26 22:46 ` [RFC PATCH v2 5/6] restore: implement noob mode Jacob Stopak
2023-10-26 22:46 ` [RFC PATCH v2 6/6] status: add advice status hints as table footer Jacob Stopak
2023-10-27 13:32 ` [RFC PATCH v2 0/6] Noobify format for status, add, restore Dragan Simic
2023-10-27 17:13 ` Jacob Stopak
2023-10-28 0:06 ` Dragan Simic
2023-10-28 2:52 ` Jacob Stopak
2023-10-28 5:55 ` Dragan Simic
2023-10-28 15:21 ` Jacob Stopak
2023-10-28 16:20 ` Dragan Simic
2023-10-28 17:35 ` Jacob Stopak
2023-10-28 17:41 ` Dragan Simic
2023-10-28 18:05 ` Jacob Stopak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZTS4jfsU6oS6LW0u.jacob@initialcommit.io \
--to=jacob@initialcommit.io \
--cc=dsimic@manjaro.org \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).