From: Jacob Stopak <jacob@initialcommit.io>
To: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Cc: Dragan Simic <dsimic@manjaro.org>, git@vger.kernel.org
Subject: Re: [RFC PATCH 0/5] Introduce -t, --table for status/add commands
Date: Mon, 23 Oct 2023 12:29:12 -0700 [thread overview]
Message-ID: <ZTbJiIkIyXwWK8JP.jacob@initialcommit.io> (raw)
In-Reply-To: <ZTa4iqe0lqn/Yg5L@ugly>
On Mon, Oct 23, 2023 at 08:16:42PM +0200, Oswald Buddenhagen wrote:
> On Mon, Oct 23, 2023 at 10:30:54AM -0700, Jacob Stopak wrote:
> > On Mon, Oct 23, 2023 at 04:34:15PM +0200, Dragan Simic wrote:
> > > On 2023-10-23 12:52, Oswald Buddenhagen wrote:
> > > > 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_
> > >
> > > I'd never support that, FWIW.
> >
> > FWIW, I'd _never suggest_ that.
> >
> why, though?
> doing that would extend the feature's reach about two orders of magnitude
> among newbies, which is where it matters most.
To be honest it never even popped into my head to contemplate that and
how the user experience might be impacted by making it the default. I
assume the big distinction is "would it help more users than it would
annoy"?
I always saw this feature as a helper to be invoked when the user is in need
as opposed to a default, similar to the -n dry run option on some commands.
For brand new users, I can see what you mean since they would likely not
know the --table format exists unless being instructed by someone else.
It would be kindof a shame for this capability to exist but not be taken
advantage of by the folks who need it most - the newbies running "git
status" literally for the very first time.
But the main drawback is that although the --table for status does provide
some visual clarity and tangibility, the status command doesn't actually
_do_ anything, so the arrows showing how changes move around don't apply.
Those arrows showing how things move only really apply to "simulating"
(dry runs) for specific commands like add, restore, rm, commit, stash,
etc, so making the --table proposal a default status output would still
miss those scenarios.
However, now that I'm thinking about it maybe it could somehow be included
in the Hints feature? I honestly don't know exactly when the hints are
currently invoked or how much detail they go into, but what just popped
into my head is kindof a "universal dry run" option, which would show the
user the --table format hint when they invoke an applicable command, and
prompt them if they actually want to run it.
>
> > I very much value Git's current usage and wouldn't dream to make this
> > the default.
> >
> making the default output format somewhat more verbose wouldn't really
> "change the usage", though. and being able to permanently get rid of it with
> a single command should alleviate any _reasonable_ concerns about habit
> disruption.
>
> regards
It's a good point too that people surprised or annoyed or disgusted by the
change of a longstanding status output format could just disable the
configuration with a single config command...
next prev parent reply other threads:[~2023-10-23 19:29 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
2023-10-23 17:59 ` Dragan Simic
2023-10-23 18:16 ` Oswald Buddenhagen
2023-10-23 19:29 ` Jacob Stopak [this message]
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=ZTbJiIkIyXwWK8JP.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).