| Message ID | 20231020183947.463882-1-jacob@initialcommit.io (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introduce -t, --table for status/add commands | expand |
On 2023-10-20 20:39, Jacob Stopak wrote: > This is a proposal / proof-of-concept for a new table-based output > format for the git status command, and for dry runs (-n) of the git add > command. This could be extended to create visual dry runs for other > other commands like rm, mv, restore, stash, commit, and clean. Huh, please don't get me wrong, but based on the examples provided below, I really think that's only wasted screen estate, providing little or no help in understanding the performed operations. I appreciate your effort, but IMHO it makes little sense from the usability standpoint. > For some context, earlier this year I released a tool called Git-Sim > (https://github.com/initialcommit-com/git-sim) which allows users to do > visual dry runs of many Git commands, which are rendered as high > quality > output image files. Simulating commands like status, add, rm, mv, > restore, > stash, and commit creates a table with 3 columns to represent the way > file > changes "move around" as a result of the command being simulated. > > I've gotten positive feedback from users about this visual approach to > simulating git commands, which is more intuitive than pure terminal > text > for both newer users to understand how git works and for visual people. > > As a result, I was thinking of ways to integrate these types of visual > formats directly into Git. A table-based output format with colored > highlighting for the commands mentioned above is low hanging fruit. > > Teach 'git status' the new -t, --table flag, which displays the status > output in a 3-column table format, preserving terminology and color > coding from the default git status "long output" format (note that the > column headers are shortened here for the small width of this email, > and > also I just realized that the tables below might not look right on the > mailing list due to the differing character width, but it looks correct > in the terminal so please test there it's more fun anyway :D): > > $ git status -t > ------------------------------------------------------------------------- > | Untracked files | Changes n...or commit | Changes t...committed > | > ------------------------------------------------------------------------- > | poiu | | > | > | status-table/ | | > | > | | | asdf > | > | | table.c | > | > | | wt-status.c | > | > ------------------------------------------------------------------------- > > Teach 'git add' the new -t, --table flag to be used ONLY in combination > with the '-n' flag for dry runs. Instead of simply printing out the > added filenames, the full status table format is displayed, along with > arrows that visually show how the added files are being moved around: > > $ git add -nt poiu wt-status.c > ------------------------------------------------------------------------- > | Untracked files | Changes n...or commit | Changes t...committed > | > ------------------------------------------------------------------------- > | poiu -----------------------------------------> poiu > | > | status-table/ | | > | > | | | asdf > | > | | table.c | > | > | | wt-status.c ----------> wt-status.c > | > ------------------------------------------------------------------------- > > Other notes: > > * The width of the table and columns are dynamically set based on the > width of the terminal. > > * Long paths are shortened to include the maximum number of characters > from both ends of the path that will fit, with a '...' in the middle. > > * Color coding matches the default output of 'git status', with > untracked files and working dir mods in red, and staged changes in > green. If needed, arrows are drawn in cyan. > > As stated above, the dry run version of the table format can be applied > to various other commands like rm, mv, restore, stash, commit, and > clean > which all move file changes around in a way that can be represented in > the table format. New columns may need to be added or arrows reversed > to show changes moving in various directions. Note that some of these > commands don't appear to have a dry run (-n) option yet, so it could be > added for consistency (if not already in use) and for use with the new > table format. > > Since this is an RFC patch series, I probably did some illegal and dumb > things in my code changes just to get it into a demo-able state. I am a > bit wary of having made changes to files like "read-cache.c" and > "read-cache-ll.h" to pass in the wt_status info, and there are probably > betters ways to do some other things too. > > Feedback on both the new format itself and the implementation is very > much appreciated! > > Jacob Stopak (5): > status: introduce -t, --table flag > status: handle long paths with -t, --table flag > status: add advice arg for -t, --table flag > add: add -t, --table flag for visual dry runs > add: set unique color for -t, --table arrows > > Makefile | 1 + > builtin/add.c | 46 +++++++-- > builtin/commit.c | 4 +- > read-cache-ll.h | 9 +- > read-cache.c | 32 ++++++- > table.c | 245 +++++++++++++++++++++++++++++++++++++++++++++++ > table.h | 6 ++ > wt-status.c | 74 +++++++++----- > wt-status.h | 3 + > 9 files changed, 378 insertions(+), 42 deletions(-) > create mode 100644 table.c > create mode 100644 table.h
On Fri, Oct 20, 2023 at 08:48:12PM +0200, Dragan Simic wrote: > On 2023-10-20 20:39, Jacob Stopak wrote: > > This is a proposal / proof-of-concept for a new table-based output > > format for the git status command, and for dry runs (-n) of the git add > > command. This could be extended to create visual dry runs for other > > other commands like rm, mv, restore, stash, commit, and clean. > > Huh, please don't get me wrong, but based on the examples provided below, I > really think that's only wasted screen estate, providing little or no help > in understanding the performed operations. > > I appreciate your effort, but IMHO it makes little sense from the usability > standpoint. > Thanks for the quick (and honest ;) reply - I appreciate it and no offense taken! But let me try to expand on my reasoning a bit. I agree with you that Git users who are already comfortable with Git, the command-line, and their workflows would be unlikely to use this in their day to day work. The main benefits of this format are for beginners and folks who are still learning Git to use it as needed: * To beginners, the concepts of working directory and "staging area" can be very abstract. By representing these concepts as table columns on the screen, (a format that 99% of humans are used to interpreting), they become more tangible and intuitive to new users. * In Git, changes fly around all over the place, in all sorts of directions. Even small hints at this movement can be very helpful to understand what the heck is going on. The table format (esp with arrows used in the 'git add' version) highlights the "flow" of changes through the workflow in a way that the current default format doesn't. The current dry runs just show the filenames being added without context of _where_ they come from and where they are going. Not to mention many commands don't even have dry runs. This might sound like a small thing, but to a newbie having that extra level of confirmation and understanding can make a big difference. * Git doesn't exactly have a reputation as a user-friendly tool, and much of that stems from the difficulty of learning Git. So we should try to make it more approachable to normal humans. This format (esp if applied to a wide variety of commands as dry runs) would provide a rudimentary visual output that is more intuitive to users. * This flag doesn't change any default behavior, it can easily be tossed on for newbie use (either when teaching a newbie or when the newbie is practicing on their own). Given this usage, the screen realestate is not really a concern. I.e. this would be used specifically when needed for the extra info/clarity it provides, not to be efficient with the terminal space. That's my perspective anyway, but of course the point of this is to propose it to the community and hear the response, so even if it's not included it's still a good experience :D.
On 2023-10-20 23:48, Jacob Stopak wrote: > On Fri, Oct 20, 2023 at 08:48:12PM +0200, Dragan Simic wrote: >> On 2023-10-20 20:39, Jacob Stopak wrote: >> > This is a proposal / proof-of-concept for a new table-based output >> > format for the git status command, and for dry runs (-n) of the git add >> > command. This could be extended to create visual dry runs for other >> > other commands like rm, mv, restore, stash, commit, and clean. >> >> Huh, please don't get me wrong, but based on the examples provided >> below, I >> really think that's only wasted screen estate, providing little or no >> help >> in understanding the performed operations. >> >> I appreciate your effort, but IMHO it makes little sense from the >> usability >> standpoint. >> > Thanks for the quick (and honest ;) reply - I appreciate it and no > offense > taken! But let me try to expand on my reasoning a bit. Thank you! > I agree with you that Git users who are already comfortable with Git, > the command-line, and their workflows would be unlikely to use this in > their day to day work. > > The main benefits of this format are for beginners and folks who > are still learning Git to use it as needed: Oh, I always do my best to put myself in the shoes of the targeted audience. Maybe I sometimes fail at that, I don't know, but that's why we're here to discuss it further. > * To beginners, the concepts of working directory and "staging area" > can be very abstract. By representing these concepts as table > columns > on the screen, (a format that 99% of humans are used to > interpreting), > they become more tangible and intuitive to new users. 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. 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. > * In Git, changes fly around all over the place, in all sorts of > directions. Even small hints at this movement can be very helpful > to > understand what the heck is going on. The table format (esp with > arrows used in the 'git add' version) highlights the "flow" of > changes through the workflow in a way that the current default > format > doesn't. The current dry runs just show the filenames being added > without context of _where_ they come from and where they are going. > Not to mention many commands don't even have dry runs. This might > sound like a small thing, but to a newbie having that extra level > of > confirmation and understanding can make a big difference. 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. > * Git doesn't exactly have a reputation as a user-friendly tool, and > much of that stems from the difficulty of learning Git. So we > should > try to make it more approachable to normal humans. This format > (esp if applied to a wide variety of commands as dry runs) would > provide a rudimentary visual output that is more intuitive to > users. 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. > * This flag doesn't change any default behavior, it can easily be > tossed on for newbie use (either when teaching a newbie or when the > newbie is practicing on their own). Given this usage, the screen > realestate is not really a concern. I.e. this would be used > specifically when needed for the extra info/clarity it provides, > not to be efficient with the terminal space. 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. > That's my perspective anyway, but of course the point of this is to > propose it to the community and hear the response, so even if it's > not included it's still a good experience :D. Let's hear more thoughts from other people, of course.
Dragan Simic <dsimic@manjaro.org> writes: > 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. You are not alone in feeling the impedance mismatch between the intended audience the patch(es) try to help (pointy-clicky GUI users) and the codebase the patch(es) modify (perhaps spartan command line interface). I did wonder why this is not made as a part of sugarcoating the command line interface with some GUI that shows what could be added, what has been added, and the stuff in its "git status" equivalent.
> 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.
On Fri, Oct 20, 2023 at 04:28:19PM -0700, Junio C Hamano wrote: > > You are not alone in feeling the impedance mismatch between the > intended audience the patch(es) try to help (pointy-clicky GUI > users) I'm sure there's overlap with "pointy-clicky GUI users" but my point isn't to directly cater to them. I find it intersting to think about how visual (and ok fine even gui) tools can be used as bridge tools that can be discarded one the important concepts are solidified, and maybe resurrected in a moment of stupidity or strife. It's like yes use the crutch if you need it, but then do it the real way once you get it. And altho this is a visual helper feature, it keeps the user within the terminal, close to the Git cli and may help some subset stay there. > and the codebase the patch(es) modify (perhaps spartan > command line interface). Git does have some comforting features doesn't it? For example the hints, as well as the nice pretty colored --graph option for log. I'm sure I'm missing some others? Isn't there a file called pretty.c?! :D > I did wonder why this is not made as a > part of sugarcoating the command line interface with some GUI that > shows what could be added, what has been added, and the stuff in its > "git status" equivalent. I'm working on a couple of tools (ok fine basically guis) that include this feature. The reason to bring it up here is that a common feedback I got on my existing tool was "add something like this into git", so I was curious about what was possible to do from the Git cli. This would obviously be the best way for the feature to reach the widest possible audience and get the most use. Any standalone tool I create would get a teensy fraction of the use that a feature in Git itself would get, so I figured I'd give it a whirl.
On 2023-10-22 07:52, Jacob Stopak wrote: >> 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. Coincidentally, yesterday I was demonstrated for the first time in my life the way VS Code works with git, by a member of the first category of users. It's dumbed down to the extreme, hiding pretty much all the details and git specifics, which is exactly what the first category wants. Now I understand why the VS Code is so much popular. The second category, myself included, tends to be genuinely disgusted by such an approach that makes everything nearly sterile. But I do understand why many users simply love it that way. Maybe I digress. >> 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. I agree, understanding the internals of some project or product, with many or all of its outer layers peeled back, is often the only way to really get to know 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. True, but I still think that having git put its thoughts into tables is actually not helpful. To be precise, it actually might be helpful, but only to the first category of users, who will never reach it. I mean, never say never, but in this case I'm pretty sure it's safe to say it. Unfortunately. >> 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. The built-in hints are useful without doubt, and in fact I still have at least a dozen of them left enabled. > And the hint feature does show that Git has some "helper" features to > hold the user's hand at least a little bit. IMHO, git strikes a very good balance between holding the user's hand and leaving them on their own. For the second category of users, of course. >> 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. I agree, software in general shouldn't cause people pain, it should make people's lives better. However, many people expect software these days to be some kind of pain killer, which it simply can't be unless dumbed down to the extreme. If you ask any doctor what results from taking pain killers for an extended period of time, they'll answer you that stronger pain killers will usually become needed.
On 2023-10-22 08:04, Jacob Stopak wrote: > On Fri, Oct 20, 2023 at 04:28:19PM -0700, Junio C Hamano wrote: >> >> You are not alone in feeling the impedance mismatch between the >> intended audience the patch(es) try to help (pointy-clicky GUI >> users) > > I'm sure there's overlap with "pointy-clicky GUI users" but my point > isn't to directly cater to them. I find it intersting to think about > how visual (and ok fine even gui) tools can be used as bridge tools > that can be discarded one the important concepts are solidified, and > maybe resurrected in a moment of stupidity or strife. > > It's like yes use the crutch if you need it, but then do it the real > way once you get it. Quite frankly, that would be like starting to learn how to drive a car by playing GTA 5, or whichever version of GTA it currently popular. I don't think that would work out well for the vast majority of student drivers. > And altho this is a visual helper feature, it keeps the user within the > terminal, close to the Git cli and may help some subset stay there. Even if that would work out for some people, it would require the formatting into tables to be the default for git, which frankly I'd never support.
On Sun, Oct 22, 2023 at 08:38:19AM +0200, Dragan Simic wrote: >True, but I still think that having git put its thoughts into tables is >actually not helpful. > i'm not convinced that the proposed feature specifically would have helped me, either (i found the index a rather obvious concept once i knew that it's there), but i'm making a general argument here. so: >To be precise, it actually might be helpful, but only to the first >category of users, who will never reach it. I mean, never say never, >but in this case I'm pretty sure it's safe to say it. > well, and i think that you're wrong about that. your categorization is simply wrong, because it assumes an incorrect static model. while for the last decade i've been as much of a git expert as one can reasonably be without being literally obsessed with it or having written much of it, i absolutely *did* start out in your first category (as in, it was forced upon me, while i couldn't have cared less about the specifics - p4 was working well enough (or so i thought)). and i hated this stupid git (it was 2009, and it was much more of a pita for noobs than it is now). i certainly could have used more sensible visualizations at every step - on the command line, because that's where i mostly "live". the second major error in the thinking is that "expert" and "gui user" are mutually exclusive categories. while i do most things on the command line, i would never voluntarily use "add -p" - why should i inflict that pain upon me, when i can simply use git-gui to do the job in a much more visual and freely navigable way? the same goes for "log --graph" vs. gitk, and git's "blame" function vs. qt creator's (or git-gui's, but i don't use it for that). regards
On 2023-10-22 12:30, Oswald Buddenhagen wrote: > On Sun, Oct 22, 2023 at 08:38:19AM +0200, Dragan Simic wrote: >> True, but I still think that having git put its thoughts into tables >> is actually not helpful. > > i'm not convinced that the proposed feature specifically would have > helped me, either (i found the index a rather obvious concept once i > knew that it's there), but i'm making a general argument here. so: > >> To be precise, it actually might be helpful, but only to the first >> category of users, who will never reach it. I mean, never say never, >> but in this case I'm pretty sure it's safe to say it. > > well, and i think that you're wrong about that. > your categorization is simply wrong, because it assumes an incorrect > static model. > > while for the last decade i've been as much of a git expert as one can > reasonably be without being literally obsessed with it or having > written much of it, i absolutely *did* start out in your first > category (as in, it was forced upon me, while i couldn't have cared > less about the specifics - p4 was working well enough (or so i > thought)). and i hated this stupid git (it was 2009, and it was much > more of a pita for noobs than it is now). i certainly could have used > more sensible visualizations at every step - on the command line, > because that's where i mostly "live". 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, especially because you migrated to git from another VCS, which you liked, and because you use the command line a lot. Full disclosure, I used Subversion for many years and I loved it. I knew it very well and it did all I needed for me and the team I worked with. Then git came and I really didn't like it, because it was touted to be "the best thing ever". 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. > the second major error in the thinking is that "expert" and "gui user" > are mutually exclusive categories. while i do most things on the > command line, i would never voluntarily use "add -p" - why should i > inflict that pain upon me, when i can simply use git-gui to do the job > in a much more visual and freely navigable way? the same goes for "log > --graph" vs. gitk, and git's "blame" function vs. qt creator's (or > git-gui's, but i don't use it for that). 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. 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.
On Sun, Oct 22, 2023 at 12:30:16PM +0200, Oswald Buddenhagen wrote: > On Sun, Oct 22, 2023 at 08:38:19AM +0200, Dragan Simic wrote: > > True, but I still think that having git put its thoughts into tables is > > actually not helpful. > > > i'm not convinced that the proposed feature specifically would have helped > me, either (i found the index a rather obvious concept once i knew that it's > there), but i'm making a general argument here. so: > Thank you for the input! One point I'd like to add is that although the current proposal patch series only implements the table option for the status and add commands, it could be applied to many others as dry runs, as mentioned in my cover letter, some of which touch on concepts besides the index. Examples would be git stash and git clean. It can take a while before all these commands feel natural, which was my hope for having this optional helper when the user simply could use a bit more clarity. > > To be precise, it actually might be helpful, but only to the first > > category of users, who will never reach it. I mean, never say never, > > but in this case I'm pretty sure it's safe to say it. > > > well, and i think that you're wrong about that. > your categorization is simply wrong, because it assumes an incorrect static > model. > > while for the last decade i've been as much of a git expert as one can > reasonably be without being literally obsessed with it or having written > much of it, i absolutely *did* start out in your first category (as in, it > was forced upon me, while i couldn't have cared less about the specifics - > p4 was working well enough (or so i thought)). and i hated this stupid git > (it was 2009, and it was much more of a pita for noobs than it is now). i > certainly could have used more sensible visualizations at every step - on > the command line, because that's where i mostly "live". > :D. I feel similar and as mentioned in a reply above, the main benefit to getting direct feedback on in the cli is that it can provide guidance based on the exact context the user is in, instead of an external resource which can in most cases only suggest a more general or tangential guidance / solution.
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
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. Actually, I see myself as some kind of a slave worker who just keeps typing on his keyboard and helps the elite (i.e. the "normal people") to enjoy their lives. In other words, my viewpoint is totally opposite of how you perceived it. >> 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? ;-) Good point. Various commands are often simply copied and pasted with little understanding. I guess that makes people content, as one of their life choices. I can respect that. >> 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. Well, I guess I'm different. As I already wrote above, I see myself as some kind of a "slave worker" who helps in enabling others (i.e. the "elite") to do whatever they want. > you should however consider whether your preferences are a good > default for the wider audience, even within the context of the command > line. Actually, some of my own preferences for my environment, when it comes to the git configuration, are not the defaults. > 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.
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.
On 2023-10-23 19:30, 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_ >>> (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. Perhaps my broad classification of git users wasn't that great, and I'm actually happy for being wrong there. Just to clarify, in general I'd support the inclusion of the table output formatting, but I'd need to test it in detail before saying a definite yes. It would also need to be more feature-complete, and the original author of the patches should commit to maintaining it as the new git feature. Having different options available can't hurt, IMHO. However, having that as the default is something I'll never support. All this is just my opinion.
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. >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
Jacob Stopak <jacob@initialcommit.io> writes: > 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: Ah, OK, now I see where your "--table" is coming from ;-). "git-sim" was exactly what I thought about when I saw it, and I did not know that "--table" came from the same set of brain cells. One thing that nobody seems to have raised that disturbs me is that even though there may be educational value in having such a "feature", having to carry the extra code to implement in Git incurs extra cost. I was reasonably happy when I saw that "git-sim" was done as a totally separate entity exactly for this reason. THanks.
On 2023-10-23 21:01, Junio C Hamano wrote: > Jacob Stopak <jacob@initialcommit.io> writes: > >> 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: > > Ah, OK, now I see where your "--table" is coming from ;-). > "git-sim" was exactly what I thought about when I saw it, and I did > not know that "--table" came from the same set of brain cells. > > One thing that nobody seems to have raised that disturbs me is that > even though there may be educational value in having such a > "feature", having to carry the extra code to implement in Git incurs > extra cost. I was reasonably happy when I saw that "git-sim" was > done as a totally separate entity exactly for this reason. That's exactly why I already wrote that the original author of the table patches, if those would become accepted, should commit in advance to maintaining that as the new git feature.
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...
On Mon, Oct 23, 2023 at 12:29:12PM -0700, Jacob Stopak wrote: >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. > you're too focused on the status quo of your own tool. :-) there is really nothing that would speak against the real commands reporting what they just *actually did*. this would seem rather helpful for noobs and other insecure users. if one really wanted, "you can also use this with --dry-run" could be part of the hint that would say how to turn off the extra verbosity (or just the hint itself, if one likes the verbosity). one could even go one step further and put at least the destructive commands into interactive/confirmation mode by default. but that's probably a bridge too far, as it would be potentially habit-forming in a bad way. regards
On 2023-10-23 21:29, Jacob Stopak wrote: > 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. That's a good idea, having the tables and dry runs mentioned in a well-placed hint that could, of course, be disabled through git configuration.
>On 2023-10-23 21:01, Junio C Hamano wrote: >> One thing that nobody seems to have raised that disturbs me is that >> even though there may be educational value in having such a >> "feature", having to carry the extra code to implement in Git incurs >> extra cost. > that's the case for literally every feature. you're just noticing it here, because from your expert perspective it seems redundant with pre-existing functionality. so assuming that you actually care about newbie UX, you are at least not convinced that it would be a significant help. i'm not totally convinced either, which is why i wrote of "valid experiment" upthread. but i don't think that measuring the actual impact is all that interesting unless the feature turns out to be actually excessively costly in the long run. On Mon, Oct 23, 2023 at 09:04:49PM +0200, Dragan Simic wrote: >That's exactly why I already wrote that the original author of the table >patches, if those would become accepted, should commit in advance to >maintaining that as the new git feature. > that's seems just a wee bit unfair (the bar isn't put that high for other features), and it's not realistically enforcable anyway. regards
On 2023-10-23 22:19, Oswald Buddenhagen wrote: > On Mon, Oct 23, 2023 at 12:29:12PM -0700, Jacob Stopak wrote: >> 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. >> > you're too focused on the status quo of your own tool. :-) > there is really nothing that would speak against the real commands > reporting what they just *actually did*. this would seem rather > helpful for noobs and other insecure users. > if one really wanted, "you can also use this with --dry-run" could be > part of the hint that would say how to turn off the extra verbosity > (or just the hint itself, if one likes the verbosity). The hint should be about how to turn the tables and verbosity on, not how to get rid of it. > one could even go one step further and put at least the destructive > commands into interactive/confirmation mode by default. but that's > probably a bridge too far, as it would be potentially habit-forming in > a bad way. > > regards
> On Mon, Oct 23, 2023 at 09:04:49PM +0200, Dragan Simic wrote: >> That's exactly why I already wrote that the original author of >> the table patches, if those would become accepted, should commit >> in advance to maintaining that as the new git feature. >> > that's seems just a wee bit unfair (the bar isn't put that high for > other features), and it's not realistically enforcable anyway. Well, it's a bit disruptive new feature, which is also quite extensive and can rather easily become obsolete if not maintained in the long run. Perhaps we should hear Jacob's thoughts about that as well.
On Mon, Oct 23, 2023 at 12:01:14PM -0700, Junio C Hamano wrote: > Ah, OK, now I see where your "--table" is coming from ;-). > "git-sim" was exactly what I thought about when I saw it, and I did > not know that "--table" came from the same set of brain cells. Haha the set is not quite the same I'm sure I've lost many over the course of this year. But the survivors are doing their best. > One thing that nobody seems to have raised that disturbs me is that > even though there may be educational value in having such a > "feature", having to carry the extra code to implement in Git incurs > extra cost. I was reasonably happy when I saw that "git-sim" was > done as a totally separate entity exactly for this reason. Erm, not to get too sappy here but I'd love to maintain anything related to this that gets implemented, in whatever form that turns out to be. I already spend way too much of my free time working on Git-related things so making this contribution to Git itself would mean a lot to me. Starting Git-Sim as a separate entity made sense to me because: * I had no idea whether anyone wanted something like this, so it would have made for a pretty weak argument to the community. (It turned out way more users were interested than I thought). * It's written in Python and relies on a dependency library called Manim, so I thought it wouldn't make any sense to try and wedge that into the Git codebase. * The output is presentation quality images / video animations, which is unlike anything I've seen outputted by any Git command. (I didn't explore what it would take to do something similar in C). The main downsides to Git-Sim as a separate tool are: * The main downside is lack of reach. Not being Git-native means only a tiny fraction of Git users will ever know it exists. * There is technically no guarantee that a simulated output actually corresponds to what the command will do, as highlighted by this comment on Hacker News: "Next HN post - "I destroyed my repo - but it WORKED in Git-Sim!" * As Git changes over time, Git-Sim is destined to be a step behind. * Certain commands (like the networked commands fetch/push/pull/etc) are not easy to simulate without doing horrible things like cloning a new copy of the repo behind the scenes, running the desired operation on it, and checking the result. I assume things like this would be a lot easier to do within Git.
On Mon, Oct 23, 2023 at 10:51:31PM +0200, Dragan Simic wrote: >The hint should be about how to turn the tables and verbosity on, not >how to get rid of it. > but that's just backwards. a noob shouldn't be bothered with putting the tool into noob-friendly mode, neither actually nor "just" psychologically. switching to "expert" mode should be the conscious effort. and making it opt-in wouldn't even save the experts any annoyance, as they need to opt out from the hint anyway. regards
On 2023-10-23 23:14, Oswald Buddenhagen wrote: > On Mon, Oct 23, 2023 at 10:51:31PM +0200, Dragan Simic wrote: >> The hint should be about how to turn the tables and verbosity on, not >> how to get rid of it. > > but that's just backwards. a noob shouldn't be bothered with putting > the tool into noob-friendly mode, neither actually nor "just" > psychologically. switching to "expert" mode should be the conscious > effort. and making it opt-in wouldn't even save the experts any > annoyance, as they need to opt out from the hint anyway. Let's focus on non-noobs as well, which could go nuts by having some strange tables displayed after updating git. For the beginners, having something configured is already inevitable, e.g. their credentials, so they could also turn on the tables if they wanted so.
On Mon, Oct 23, 2023 at 10:59:08PM +0200, Dragan Simic wrote: > > On Mon, Oct 23, 2023 at 09:04:49PM +0200, Dragan Simic wrote: > > > That's exactly why I already wrote that the original author of > > > the table patches, if those would become accepted, should commit > > > in advance to maintaining that as the new git feature. > > > > > that's seems just a wee bit unfair (the bar isn't put that high for > > other features), and it's not realistically enforcable anyway. > > Well, it's a bit disruptive new feature, which is also quite extensive and > can rather easily become obsolete if not maintained in the long run. > Perhaps we should hear Jacob's thoughts about that as well. I would love to work on implementing this and maintaining it! I spend too much time doing Git things for no reason anyway so why not? :D But... I could die at the hands of an angry user and then you would have to take over, Dragan...
On 2023-10-23 23:23, Jacob Stopak wrote: > On Mon, Oct 23, 2023 at 10:59:08PM +0200, Dragan Simic wrote: >> > On Mon, Oct 23, 2023 at 09:04:49PM +0200, Dragan Simic wrote: >> > > That's exactly why I already wrote that the original author of >> > > the table patches, if those would become accepted, should commit >> > > in advance to maintaining that as the new git feature. >> > > >> > that's seems just a wee bit unfair (the bar isn't put that high for >> > other features), and it's not realistically enforcable anyway. >> >> Well, it's a bit disruptive new feature, which is also quite extensive >> and >> can rather easily become obsolete if not maintained in the long run. >> Perhaps we should hear Jacob's thoughts about that as well. > > I would love to work on implementing this and maintaining it! I spend > too much time doing Git things for no reason anyway so why not? :D Awesome! Quite frankly, I expected to hear that. :) > But... I could die at the hands of an angry user and then you would > have > to take over, Dragan... Or I could instead try to help you fending off angry git users? :)
On Mon, Oct 23, 2023 at 10:19:47PM +0200, Oswald Buddenhagen wrote: > On Mon, Oct 23, 2023 at 12:29:12PM -0700, Jacob Stopak wrote: > > 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. > > > you're too focused on the status quo of your own tool. :-) Ha it's possible. I created git-sim with a very specific use case in mind so you're right it's probably worth rethinking that while taking into account Git's other functionality that wasn't in the picture with an external tool. > there is really nothing that would speak against the real commands reporting > what they just *actually did*. this would seem rather helpful for noobs and > other insecure users. That's true, it would be just as easy to report the results of a command (and even easier in some cases) than forecasting the result in a dry-run. The question is how to decide which one? Do you report the results of certain commands by default while hints are enabled? And only as a dry run when the --dry-run / -n flag is added? That actually would make sense as it wouldn't add "special" behavior to the dry run. The dry run would just report the exact same default output as the normal command, but omit the action. > if one really wanted, "you can also use this with --dry-run" could be part > of the hint that would say how to turn off the extra verbosity (or just the > hint itself, if one likes the verbosity). Interesting. So many ways to think about how to optimize the user interaction... > one could even go one step further and put at least the destructive commands > into interactive/confirmation mode by default. but that's probably a bridge > too far, as it would be potentially habit-forming in a bad way. That would be an interesting add on to our discussion above. So as a thought experiment, let's pretend there are no restrictions from traditional users, we could: 1) Enable verbose results output by default to certain commands, which could include a visual table-based output where applicable, and a hint to disable it. (Are hints currently command-specific? Or even scenario-specific within a command? Or is it all or nothing?) 2) Include verbose/table results on dry runs, and add dry run flags onto commands that should seem to have it for consistency. For example "git add" has a dry run flag but "git restore" (the hinted inverse operation) does not. I assume on dry runs hints wouldn't be used to communicate anything. 3) Well, I'll admit about once every 3 months I run "git stash --all" when I really meant "git stash --include-untracked" and proceed to lose a small part of my soul. This would be saved by a simple confirmation. I find that the stuff like "git reset --hard" doesn't bother me anymore since I know when to be careful with it and what things I can get back and how to do it. But I find the nasty ones are the things that sound like what you want but end up doing something bad. Not sure there is a way to isolate those though... I'm rambling now. But maybe for interactivity, at the very least it could be added to dry runs, like a "Here's what would happen, want to run it now?" I got this feedback a few times for git-sim as well.
On 2023-10-24 01:17, Jacob Stopak wrote: > That's true, it would be just as easy to report the results of a > command > (and even easier in some cases) than forecasting the result in a > dry-run. > The question is how to decide which one? Do you report the results of > certain commands by default while hints are enabled? And only as a dry > run > when the --dry-run / -n flag is added? That actually would make sense > as > it wouldn't add "special" behavior to the dry run. The dry run would > just > report the exact same default output as the normal command, but omit > the action. IMHO, it would be the best to simply implement support for "<command>.verbose = table" in the git configuration, similarly to how we already have "commit.verbose = true". That way tables could be enabled per command, according to the user's preferences, regardless of performing dry runs or not. The new hint would be placed somewhere, which should be decided separately, but having the hint enabled or disabled wouldn't affect anything else. Just like with the other hints.
Dragan Simic <dsimic@manjaro.org> writes: > IMHO, it would be the best to simply implement support for > "<command>.verbose = table" in the git configuration, similarly to how > we already have "commit.verbose = true". That way tables could be > enabled per command, according to the user's preferences, regardless > of performing dry runs or not. I think the "use more verbose report format to help relatively inexperienced folks, in exchange for spending more screen real estate" is a good direction to think about this thing. I am not personally interested in adding such support all that much myself, but one piece of advice I can offer those who are interested is not to be too deeply attached to the word "table". It may be that "git status" (not "status -s" [*] but the current version for human consumption) shows "paths with changes to be committed (i.e. changes added to the index exist)" and "paths with changes you could add to the index (i.e. changes yet to be added to the index exist)" in a separate list, and Jacob may have found that it gives a more understandable view into the states of each path if the output is turned 90-degrees and the changes are shown in a tabular form. But "table" in this example is merely an implementation detail of one presentation that is easier to understand for "git status", and calling it "table" and making it a word in the vocabulary of <command>.verbose is like a tail wagging the dog. We want to convey to the users that the option is about "with extra verbosity, the user is buying a bit more clarity", not necessarily "use tabular form no matter what". For some of the commands, tabular presentation might not even be the presentation form that is the easiest to understand to novices. For example, I just pushed out today's integration result to some of my repositories, and "git push" output looks like so: To github.com:gitster/git.git + 5cb4030332...7dc6f5ada8 ak/color-decorate-symbols -> ak/colo... + a71066b71b...c80a646458 jch -> jch (forced update) + 89a1ffc6a4...416cdf7260 seen -> seen (forced update) + 7ff160463b...2c610ca9ff tb/merge-tree-write-pack -> tb/merge... 2e3b7b2460..57243409ad refs/notes/amlog -> refs/notes/amlog This is already "tabular" and gives enough information to tell me which ones did not get updated (e.g., I do not see 'next' there) and which ones are forced ('jch' and 'seen' are usually forced and I'll notice that I may have made mistakes if they are not). But a hypothetical presentation that is easier for novices to read may show "git log --oneline --graph old...new" (or some abbreviated form of it) between the old and new tips of the affected branches. At that point, calling the improved output as "table" would make little sense. For commands that Jacob found it easier to explain in tabular form, like "git add", it is very possible that two years down the road, another Jacob comes around and proposes a different presentation that is even easier for novices to understand, and it may not be a tabular form. So be very careful when choosing what to call this new thing, and avoid naming it after the implementation details (e.g., in what particular shape the data gets presented) that may turn out not to be the most important part of the concept. [Footnote] * FWIW, "git status -s" is a tabular presentation. Maybe we can add a more verbose form of "-s" and be done with it for the command?
On 2023-10-24 04:03, Junio C Hamano wrote: > I think the "use more verbose report format to help relatively > inexperienced folks, in exchange for spending more screen real > estate" is a good direction to think about this thing. > > I am not personally interested in adding such support all that much > myself, but one piece of advice I can offer those who are interested > is not to be too deeply attached to the word "table". > > ... snip ... > > So be very careful when choosing what to call this new thing, and > avoid naming it after the implementation details (e.g., in what > particular shape the data gets presented) that may turn out not to > be the most important part of the concept. Totally agreed, "table" simply sneaked in and remained here as the term. Perhaps "<command>.verbose = extra" or something similar would be a good choice. > [Footnote] > > * FWIW, "git status -s" is a tabular presentation. Maybe we can > add a more verbose form of "-s" and be done with it for the > command? That's also an option.
On 2023-10-24 04:21, Dragan Simic wrote: > On 2023-10-24 04:03, Junio C Hamano wrote: >> I think the "use more verbose report format to help relatively >> inexperienced folks, in exchange for spending more screen real >> estate" is a good direction to think about this thing. >> >> I am not personally interested in adding such support all that much >> myself, but one piece of advice I can offer those who are interested >> is not to be too deeply attached to the word "table". >> >> ... snip ... >> >> So be very careful when choosing what to call this new thing, and >> avoid naming it after the implementation details (e.g., in what >> particular shape the data gets presented) that may turn out not to >> be the most important part of the concept. > > Totally agreed, "table" simply sneaked in and remained here as the > term. Perhaps "<command>.verbose = extra" or something similar would > be a good choice. Just a brief update... Some of the associated patches are already ready to go, and some more are still pending to be implemented. It took me a while, which I apologize for, and now I've also unfortunately contracted some really bad flu. I'll be back to the patches as soon as the flu decides to go away. >> [Footnote] >> >> * FWIW, "git status -s" is a tabular presentation. Maybe we can >> add a more verbose form of "-s" and be done with it for the >> command? > > That's also an option.
On Fri, Jan 05, 2024 at 08:14:34PM +0100, Dragan Simic wrote: > > Just a brief update... Some of the associated patches are already ready to > go, and some more are still pending to be implemented. It took me a while, > which I apologize for, and now I've also unfortunately contracted some > really bad flu. I'll be back to the patches as soon as the flu decides to > go away. Hey! No worries - thanks for letting me know. I have been thinking about this and am looking forward to getting back to it. Hope you recover quickly. Please include me when those patches are ready. Then I will try to align my previous patches with them and also I have a bunch of restructuring/refactoring to do based on the previous feedback from Junio. Oh and happy new year.
On 2024-01-06 05:44, Jacob Stopak wrote: > On Fri, Jan 05, 2024 at 08:14:34PM +0100, Dragan Simic wrote: >> >> Just a brief update... Some of the associated patches are already >> ready to >> go, and some more are still pending to be implemented. It took me a >> while, >> which I apologize for, and now I've also unfortunately contracted some >> really bad flu. I'll be back to the patches as soon as the flu >> decides to >> go away. > > Hey! No worries - thanks for letting me know. I have been thinking > about this > and am looking forward to getting back to it. > > Hope you recover quickly. Please include me when those patches are > ready. Then > I will try to align my previous patches with them and also I have a > bunch of > restructuring/refactoring to do based on the previous feedback from > Junio. I hope to recover soon. It's been already about two miserable weeks since the flu symptoms started, and it has since moved into my lungs, making things much worse than usual. Sure, I'll also include a brief summary of our earlier discussions into the cover letter, with the links to the mailing list archives, to provide context for the patches for everyone reviewing them later. Looking forward to these new git features! > Oh and happy new year. Happy New Year to you too, and to everybody on the mailing list! :)