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

From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date: Oct 23, 2023, 10:52 UTC
Message-ID: <ZTZQZhtTxvGT/s81@ugly>
In-Reply-To: <58a6a25a7b2eb82c21d9b87143033cef@manjaro.org>

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? ;-)

Show 6 quoted lines

>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