git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jacob Stopak <jacob@initialcommit.io>
To: Dragan Simic <dsimic@manjaro.org>
Cc: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>, git@vger.kernel.org
Subject: Re: [RFC PATCH 0/5] Introduce -t, --table for status/add commands
Date: Mon, 23 Oct 2023 10:30:54 -0700	[thread overview]
Message-ID: <ZTatzlzCkPOW3Rn7.jacob@initialcommit.io> (raw)
In-Reply-To: <bc55e29274da0d8059a8cd4383aa1b22@manjaro.org>

On Mon, Oct 23, 2023 at 04:34:15PM +0200, Dragan Simic wrote:
> On 2023-10-23 12:52, Oswald Buddenhagen wrote:
> > On Sun, Oct 22, 2023 at 02:55:05PM +0200, Dragan Simic wrote:
> > > Oh, that's awesome and I'm really happy to be wrong with my broad
> > > classification of VCS users.  However, I still need to be convinced
> > > further, and I'd assign your example as an exception to the rules,
> > 
> > i don't see myself as exceptional at all in that regard.
> > in fact, your second user group seems like unicorns, and the first
> > like a disparaging attitude from an elitist. in reality, users lie on
> > a spectrum of willingness to engage with the details of the tools they
> > use, and that willingness is circumstantial. a tool that is
> > forthcoming with information has a higher chance of being actively
> > engaged.

Just a note here, in my initial reply I was thinking of writing something
similar about how in reality users of a tool as ubiquitous as Git would
form a continuous spectrum in terms of their usage habits and trying to
neatly plop them into 2 categories by speculating on their motives is
an oversimplification to the point where it might not be so helpful
evaluating whether an option like this would make sense to implement.

To me the bigger question is much simpler:

"Would this feature improve the Git experience for a signficant number
of users?"

I have some evidence to support the claim that it would.

My Git-Sim tool does essentially what this proposal suggests and it has
about 31,000 installs since I released it early this year. Granted this
is a drop in the bucket in the grand scheme of things, but it still shows
that there is demand for such a thing.

Git-Sim is a visual dry-run tool for Git that creates images simulating
what the corresponding Git command will do, without actually making any
change to the underlying repo state. Another important aspect is that
command syntax mimics Git's exactly - so to simulate any Git command, like:

$ git add asdf.txt qwer.txt

You would just replace the executable name and run:

$ git-sim add asdf.txt qwer.txt

and it will show you in an image exactly what will happen.

This is important because even simulating the command requires the user
to know and use the Git CLI syntax for the command. It keeps them on the
command line to do all of their actual work, unlike other true "pointy
clicky GUI's" I've seen which expect the user to do all their work in the
GUI. In fact this tool and feature expect no pointing or clicking at all.

The purpose of this is that users actually do all their work in the CLI
and learn to use Git as intuitively as possible, the way the "spartan"
CLI folks use it, the way it is meant to be used.

The reason to include a format like this in Git instead of just in my
tool is simply to reach a wider audience and benefit more people. Of
course it also appears much more trustworthy when a feature is part of
the native tool itself instead of some external thing.

> > i for one think that it would be a perfectly valid experiment to go
> > all-in and beyond with jacob's proposal - _and make it the default_
> > (when the output is a tty). more advanced users who feel annoyed would
> > be expected to opt out of it via configuration, as they are for the
> > advice messages. because it's really the same idea, only thought
> > bigger.
> 
> I'd never support that, FWIW.

FWIW, I'd _never suggest_ that. I very much value Git's current usage
and wouldn't dream to make this the default. This proposal is for an
optional flag to help users who would benefit from it, nothing more,
nothing less. Speculating on user motives to classify them into 2 broad
categories in order to prove the feature isn't helpful misses the point
that there is a (relatively large IMO) subset of users who would benefit
from it.

As an optional flag, experienced users wouldn't bat an eyelash, and the
type of users who installed my tool could use the flag on and off until
they feel confident enough to drop it. But it is always there in case
they need a refresher.

  reply	other threads:[~2023-10-23 17:31 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
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 [this message]
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=ZTatzlzCkPOW3Rn7.jacob@initialcommit.io \
    --to=jacob@initialcommit.io \
    --cc=dsimic@manjaro.org \
    --cc=git@vger.kernel.org \
    --cc=oswald.buddenhagen@gmx.de \
    /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).