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

[Oswald Buddenhagen <oswald.buddenhagen@gmx.de>]

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.

> especially because you migrated to git from another VCS,
>
that isn't all that uncommon, esp. in the older cohorts. and unless git 
achieves a total monopoly, it will remain a regular occurence.

but i don't see how that advances your argument anyway.

> which you liked,
>
i didn't say that.

> and because you use the command line a lot.
>
in my experience, this isn't uncommon for users of "discrete" vcs'es at 
all, even if they aren't too interested in the details. they just copy 
"magic incantations" from stackoverflow, etc. - disgusting, right? ;-)

>After using git for a while, I can firmly say that git is awesome, but 
>that it also is a total overkill for many projects that need a VCS, for 
>which choosing Subversion would be a much batter choice.  Why, you'll 
>ask?  Because Subversion is many times simpler, and because many 
>projects actually don't need a distributed VCS.
>
that line of reasoning seems mostly bogus to me. every project can 
benefit from using a dvcs - reviewing and polishing the history prior to 
publication leads to higher quality (primarily of the history, but such 
polishing often also transpires to the code itself), so encouraging it 
is a useful default (of course interested users can just use git-svn, 
but that's a bigger step than just having a closer look at what was 
shoved in their faces).

git is indeed pretty much by definition many times harder than svn, 
simply because it splits the process of submission into three stages.  
however, this is not a _useful_ definition, as everyone can remember to 
use `git commit -a && git push` instead of `svn commit`. the real 
complexity comes from all the interesting things one can do because of 
the split stages, but that's optional (well, until you need to pull and 
you get a merge conflict - unlike with svn, git leaves the repo in a 
"weird" state, and the poor communication of that was in fact the major 
source of frustration for me when i started).

>I also ask myself why would I use git-gui or any other GUI utility?  To 
>me, clicking on something that represents a file is often simply wrong.  
>
that makes you an outlier. most people find point-and-click interaction 
rather intuitive and significantly more efficient than encoding their 
intent into character sequences.

also, i said "add -p". selecting hunks (and even single lines) plays in 
a wholly different league than whole files.

>Though, I understand that many people prefer GUI utilities and I 
>respect that, everyone is free to do anything, but I also expect others 
>to respect my own preferences.
>
where did anyone even suggest disrespecting your preferences?

you should however consider whether your preferences are a good default 
for the wider audience, even within the context of the command line.

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.

regards