| Message ID | 20231026224615.675172-1-jacob@initialcommit.io (mailing list archive) |
|---|---|
| Headers | show |
| Series | Noobify format for status, add, restore | expand |
On 2023-10-27 00:46, Jacob Stopak wrote: > Take into account reviewer feedback by doing several things > differently: > > * Rename this feature (for now) as "noob format mode" (or just "noob > mode") instead of the original "--table" verbiage. As pointed out, > this no longer ties the name of the setting to it's proposed > implementation detail as a table. Noob mode is not necessarily the > right name, just a placeholder for now. Unless people like it :D > > * Instead of manually having to invoke the -t, --table every time > this > format is to be used, set the config option "status.noob" to true. > Although this is logically tied to the status command, there are > many > commands that produce status output, (and this series adds more), > so > assume that if the user wants to see the status this way, that it > should be enabled whenever the status info is displayed. How would "status.noob" relate to and coexist with possible future configuration options named "<command>.verbose", which would be somewhat similar to the currently existing "commit.verbose" option? IOW, perhaps it would be better to have per-command options "<command>.verbose = noob" or, even better, "<command>.verbose = extended", to make it all more future-proof and more granular. > * When running "git add" and "git restore" while noob mode is > enabled, > perform the add/restore function as usual, but display the table > formatted output with arrows showing how file changes moved around. > Displaying the output in this understandable format after each > command execution allows the noob to immediately see what they did. > Although this series only implements for status, add, and restore, > this output format would make sense in other commands like rm, mv, > commit, clean, and stash. > > * Works consistently with commands that already have a --dry-run > (-n) option. The dry run shows the exact same output, but > doesn't actually do the thing. > > * If `advice.statusHints` is true, add a table footer with status > hints. > Shorten these hints so that they are still clear but better fit > into a > table. Make the hint text yellow to distinguish them. The hints > only > appear when explicitly running "git status", which helps the user > answer the question "what can I do next?". Hints are omitted in > "impact" commands like add and restore. Having hints here distracts > from the file change moves being showed in the table by arrows. > > TODO: > > * "git status" outputs myriad other information depending on the > state > of the repo, like branch info, merge conflicts, rebase info, > bisect, > etc. Need to think about how to convey that info with the new > setting. > > * Some commands (like stash) might need more than 3 table columns to > display everything clearly. > > * For destructive commands, think about adding a prompt describing > the > effect, so the user can confirm before the action is taken. > > * Fix horrible things in the patch series code. > > * Probably other things. > > Play around with it! It's fun! > > Jacob Stopak (6): > status: add noob format from status.noob config > status: handle long paths in noob format > add: implement noob mode > add: set unique color for noob mode arrows > restore: implement noob mode > status: add advice status hints as table footer > > Makefile | 2 + > builtin/add.c | 47 +++++-- > builtin/checkout.c | 46 +++++-- > builtin/commit.c | 157 +---------------------- > commit.c | 2 + > noob.c | 198 +++++++++++++++++++++++++++++ > noob.h | 21 ++++ > read-cache-ll.h | 10 +- > read-cache.c | 41 +++++- > table.c | 301 +++++++++++++++++++++++++++++++++++++++++++++ > table.h | 6 + > wt-status.c | 75 +++++++---- > wt-status.h | 6 + > 13 files changed, 708 insertions(+), 204 deletions(-) > create mode 100644 noob.c > create mode 100644 noob.h > create mode 100644 table.c > create mode 100644 table.h
On Fri, Oct 27, 2023 at 03:32:40PM +0200, Dragan Simic wrote: > On 2023-10-27 00:46, Jacob Stopak wrote: > > Take into account reviewer feedback by doing several things differently: > > > > * Rename this feature (for now) as "noob format mode" (or just "noob > > mode") instead of the original "--table" verbiage. As pointed out, > > this no longer ties the name of the setting to it's proposed > > implementation detail as a table. Noob mode is not necessarily the > > right name, just a placeholder for now. Unless people like it :D > > > > * Instead of manually having to invoke the -t, --table every time this > > format is to be used, set the config option "status.noob" to true. > > Although this is logically tied to the status command, there are > > many > > commands that produce status output, (and this series adds more), so > > assume that if the user wants to see the status this way, that it > > should be enabled whenever the status info is displayed. > > How would "status.noob" relate to and coexist with possible future > configuration options named "<command>.verbose", which would be somewhat > similar to the currently existing "commit.verbose" option? IOW, perhaps it > would be better to have per-command options "<command>.verbose = noob" or, > even better, "<command>.verbose = extended", to make it all more > future-proof and more granular. Hmm, do there currently exist other <command>.verbose config settings besides for commit? From what I can tell from "git help config", the commit.verbose setting is the only one I see, and it just adds the diff info into the editor if the user runs git commit without the -m flag, but otherwise there seems to be no extra verbosity outputted. I noticed that git add and git mv have "verbose" (-v, --verbose) cli flags which just output the name of the file being added or renamed, and that certain other commands like git branch has a verbose output which includes the branch head commit hash and message in the output, so I guess this one is actually kindof verbose in that it outputs more than the non-empty default output. So it seems like currently "verbose" is used for various things among the command set, sometimes meaning "add something into the template if one is used" or "add some tiny output to a command that has no default output" (which still seems more "--shy" than "--verbose" :P) or "add some additional output to a command that already has some sparse output". Another thing is that commands like status have multiple flags that can be used to specify the output format, such as --short, --long, --porcelain, etc, but only --short seems to be configurable as a git config setting. Is there a reason (besides backward compatibility I guess) that these aren't rolled into a single thing like --format=<type>? This seems like it would be the easiest way to future proof for new formats like --format=verbose, --format=noob, --format=extended, etc. From a noob's perspective though, does adding a config setting for each command really make sense? I'm kindof envisioning this setting now as a "mode" that is either enabled for all commands it affects or for none. And it's highly unlikely a newish user would individually discover which commands this "extended" format is available for, and run "git config <command>.verbose = extended" for every one. I mean we could do that in case there are folks who only want it for specific commands, but to fulfill it's purpose I think there should definetely be some general way to enable the setting for all commands that have it.
On 2023-10-27 19:13, Jacob Stopak wrote: > On Fri, Oct 27, 2023 at 03:32:40PM +0200, Dragan Simic wrote: >> On 2023-10-27 00:46, Jacob Stopak wrote: >> > Take into account reviewer feedback by doing several things differently: >> > >> > * Rename this feature (for now) as "noob format mode" (or just "noob >> > mode") instead of the original "--table" verbiage. As pointed out, >> > this no longer ties the name of the setting to it's proposed >> > implementation detail as a table. Noob mode is not necessarily the >> > right name, just a placeholder for now. Unless people like it :D >> > >> > * Instead of manually having to invoke the -t, --table every time this >> > format is to be used, set the config option "status.noob" to true. >> > Although this is logically tied to the status command, there are >> > many >> > commands that produce status output, (and this series adds more), so >> > assume that if the user wants to see the status this way, that it >> > should be enabled whenever the status info is displayed. >> >> How would "status.noob" relate to and coexist with possible future >> configuration options named "<command>.verbose", which would be >> somewhat >> similar to the currently existing "commit.verbose" option? IOW, >> perhaps it >> would be better to have per-command options "<command>.verbose = noob" >> or, >> even better, "<command>.verbose = extended", to make it all more >> future-proof and more granular. > > Hmm, do there currently exist other <command>.verbose config settings > besides for commit? From what I can tell from "git help config", the > commit.verbose setting is the only one I see, and it just adds the diff > info into the editor if the user runs git commit without the -m flag, > but > otherwise there seems to be no extra verbosity outputted. They currently don't exist, but that's something I've planned to implement, e.g. to "add.verbose" as a new configuration option. It should be usable, while not being messy or intrusive as a new feature. > I noticed that git add and git mv have "verbose" (-v, --verbose) cli > flags > which just output the name of the file being added or renamed, and that > certain other commands like git branch has a verbose output which > includes > the branch head commit hash and message in the output, so I guess this > one > is actually kindof verbose in that it outputs more than the non-empty > default output. Yes, those are the basic per-command verbosity modes or levels, as I call them. The way I see it, your patches would add new, extended per-command verbosity levels. > So it seems like currently "verbose" is used for various things among > the > command set, sometimes meaning "add something into the template if one > is > used" or "add some tiny output to a command that has no default output" > (which still seems more "--shy" than "--verbose" :P) or "add some > additional output to a command that already has some sparse output". Yes, that's the basic verbosity, as I named it above. > Another thing is that commands like status have multiple flags that can > be > used to specify the output format, such as --short, --long, > --porcelain, > etc, but only --short seems to be configurable as a git config setting. > Is there a reason (besides backward compatibility I guess) that these > aren't rolled into a single thing like --format=<type>? This seems like > it would be the easiest way to future proof for new formats like > --format=verbose, --format=noob, --format=extended, etc. That's a good question, but I'd need to go through the commit history to be able to provide some kind of an explanation. It could also be all packed into "status.verbose" as a new configuration option. > From a noob's perspective though, does adding a config setting for each > command really make sense? I'm kindof envisioning this setting now as a > "mode" that is either enabled for all commands it affects or for none. > And it's highly unlikely a newish user would individually discover > which > commands this "extended" format is available for, and run "git config > <command>.verbose = extended" for every one. I mean we could do that > in case there are folks who only want it for specific commands, but to > fulfill it's purpose I think there should definetely be some general > way > to enable the setting for all commands that have it. Quite frankly, we shouldn't expect that all users are noobs, and as a result dumb everything down just to make them as comfortable as possible. On the other hand, perhaps not everyone would like to have extended verbosity enabled for all commands, just as not everyone uses "-v" for all commands.
> They currently don't exist, but that's something I've planned to implement, > e.g. to "add.verbose" as a new configuration option. It should be usable, > while not being messy or intrusive as a new feature. "git add" already has the -v, --verbose flag available for the command itself like: $ git add -v foo.txt add 'foo.txt' But like you said the config option add.verbose doesn't seem to exist yet. So I assume an "add.verbose" config option would just always print that without having to specify the -v, --verbose flag when running the command? Basically what I'm asking is if commands that already have a --verbose flag would just get a config setting that does the existing thing by default? > Yes, those are the basic per-command verbosity modes or levels, as I call > them. The way I see it, your patches would add new, extended per-command > verbosity levels. Ok, I see. > > So it seems like currently "verbose" is used for various things among > > the command set... > Yes, that's the basic verbosity, as I named it above. Would it make sense to try to define a more consistent type of output or format style for "verbosity" across different commands? As it stands it seems each command treats verbosity in its own way which makes it hard to interpret exactly what it will do each time... > > Another thing is that commands like status have multiple flags that can > > be > > used to specify the output format, such as --short, --long, --porcelain, > > etc, but only --short seems to be configurable as a git config setting. > > Is there a reason (besides backward compatibility I guess) that these > > aren't rolled into a single thing like --format=<type>? This seems like > > it would be the easiest way to future proof for new formats like > > --format=verbose, --format=noob, --format=extended, etc. > > That's a good question, but I'd need to go through the commit history to be > able to provide some kind of an explanation. It could also be all packed > into "status.verbose" as a new configuration option. Ok so it sounds like you prefer to use "verbose" as the setting key? I guess at this point that might make more sense since commit.verbose already exists, and existing options could be packed into it like you said instead of just true or false. And then my thing here would just be called "command.verbose = extended"? > > From a noob's perspective though, does adding a config setting for each > > command really make sense? I'm kindof envisioning this setting now as a > > "mode" that is either enabled for all commands it affects or for none. > > And it's highly unlikely a newish user would individually discover which > > commands this "extended" format is available for, and run "git config > > <command>.verbose = extended" for every one. I mean we could do that > > in case there are folks who only want it for specific commands, but to > > fulfill it's purpose I think there should definetely be some general way > > to enable the setting for all commands that have it. > > Quite frankly, we shouldn't expect that all users are noobs, and as a result > dumb everything down just to make them as comfortable as possible. On the > other hand, perhaps not everyone would like to have extended verbosity > enabled for all commands, just as not everyone uses "-v" for all commands. I agree with this, and I think it's important to cater to both newbies and experienced users alike. That's why I said I never dreamed of making this new format the default. And it's true that some users might only want the extended (or any format) for specific commands. I think a happy medium then is to have the command- specific settings like you mention, plus one toplevel option that enables a specific type of output format among all commands (and overrides the command-specific settings), so that the user can choose which they prefer. Any thoughts on what the section in the config for a more general setting like this might be named? If "status.verbose = extended" would already be taken specifically for the status command, what terminology could we use to mean something like "global.verbose = extended" or "global.extended = true"? Although the former seems better to me since other format values could be implemented, like "global.verbose = standard"...
On 2023-10-28 04:52, Jacob Stopak wrote: >> They currently don't exist, but that's something I've planned to >> implement, >> e.g. to "add.verbose" as a new configuration option. It should be >> usable, >> while not being messy or intrusive as a new feature. > > "git add" already has the -v, --verbose flag available for the command > itself like: > > $ git add -v foo.txt > add 'foo.txt' > > But like you said the config option add.verbose doesn't seem to exist > yet. > > So I assume an "add.verbose" config option would just always print that > without having to specify the -v, --verbose flag when running the > command? Yes, that's how I see it. Setting "add.verbose" to "true", to be precise, or to "basic", which I'll explain a bit further later in my response. > Basically what I'm asking is if commands that already have a --verbose > flag > would just get a config setting that does the existing thing by > default? Well, not by default. The default values would remain "false", so nothing jumps out of nowhere. >>> So it seems like currently "verbose" is used for various things among >>> the command set... >> >> Yes, that's the basic verbosity, as I named it above. > > Would it make sense to try to define a more consistent type of output > or > format style for "verbosity" across different commands? As it stands it > seems each command treats verbosity in its own way which makes it hard > to > interpret exactly what it will do each time... We'd have to follow the already established behavior of the commands, and there are the man pages to describe what's going on with the verbosity for each command. In other words, nothing would get changed, just some more knobs would be added, for those who prefer to have the additional verbosity enabled. >>> Another thing is that commands like status have multiple flags that >>> can be >>> used to specify the output format, such as --short, --long, >>> --porcelain, >>> etc, but only --short seems to be configurable as a git config >>> setting. >>> Is there a reason (besides backward compatibility I guess) that these >>> aren't rolled into a single thing like --format=<type>? This seems >>> like >>> it would be the easiest way to future proof for new formats like >>> --format=verbose, --format=noob, --format=extended, etc. >> >> That's a good question, but I'd need to go through the commit history >> to be >> able to provide some kind of an explanation. It could also be all >> packed >> into "status.verbose" as a new configuration option. > > Ok so it sounds like you prefer to use "verbose" as the setting key? > I guess at this point that might make more sense since commit.verbose > already exists, and existing options could be packed into it like you > said instead of just true or false. It looks like a logical choice to me. > And then my thing here would just be called "command.verbose = > extended"? Yes, that's what I propose. It also looks like a logical choice to me, and it would leave space for some possible later changes to the "<command>.verbose = extended" verbosity, without tying it to the tables. We'd also leave some space that way for even maybe an additional level of verbosity, be it "<command>.verbose = simple", "<command>.verbose = graphical" or whatever. Perhaps this scheme should also support "<command>.verbose = basic", which would be an alias for "<command>.verbose = true", for additional clarity. >>> From a noob's perspective though, does adding a config setting for >>> each >>> command really make sense? I'm kindof envisioning this setting now as >>> a >>> "mode" that is either enabled for all commands it affects or for >>> none. >>> And it's highly unlikely a newish user would individually discover >>> which >>> commands this "extended" format is available for, and run "git config >>> <command>.verbose = extended" for every one. I mean we could do that >>> in case there are folks who only want it for specific commands, but >>> to >>> fulfill it's purpose I think there should definetely be some general >>> way >>> to enable the setting for all commands that have it. >> >> Quite frankly, we shouldn't expect that all users are noobs, and as a >> result >> dumb everything down just to make them as comfortable as possible. On >> the >> other hand, perhaps not everyone would like to have extended verbosity >> enabled for all commands, just as not everyone uses "-v" for all >> commands. > > I agree with this, and I think it's important to cater to both newbies > and > experienced users alike. That's why I said I never dreamed of making > this > new format the default. Perhaps it would also be good to nudge the newbies a bit by requesting them to enable the extended verbosity for each command by hand. That way they would both learn a bit about the way git configuration works, which they ultimately can't escape from, and they would be excited to learn new git commands. Or I at least hope so. :) > And it's true that some users might only want the extended (or any > format) > for specific commands. I think a happy medium then is to have the > command- > specific settings like you mention, plus one toplevel option that > enables a > specific type of output format among all commands (and overrides the > command-specific settings), so that the user can choose which they > prefer. That's something we can consider as an additional configuration option. That way, users could also enable the basic verbosity for all commands, which may also be usable. > Any thoughts on what the section in the config for a more general > setting > like this might be named? If "status.verbose = extended" would already > be > taken specifically for the status command, what terminology could we > use > to mean something like "global.verbose = extended" or "global.extended > = > true"? Although the former seems better to me since other format values > could be implemented, like "global.verbose = standard"... Maybe "core.verbose"? We already have "core.pager", which kind of affects the way all command outputs look like.
On Sat, Oct 28, 2023 at 07:55:31AM +0200, Dragan Simic wrote: > > So I assume an "add.verbose" config option would just always print that > > without having to specify the -v, --verbose flag when running the > > command? > > Yes, that's how I see it. Setting "add.verbose" to "true", to be precise, > or to "basic", which I'll explain a bit further later in my response. Ok, gotcha! > > Basically what I'm asking is if commands that already have a --verbose > > flag > > would just get a config setting that does the existing thing by default? > > Well, not by default. The default values would remain "false", so nothing > jumps out of nowhere. Right, sorry, I worded that poorly. > > > > So it seems like currently "verbose" is used for various things among > > > > the command set... > > > > > > Yes, that's the basic verbosity, as I named it above. Ok. > > Would it make sense to try to define a more consistent type of output or > > format style for "verbosity" across different commands? As it stands it > > seems each command treats verbosity in its own way which makes it hard > > to interpret exactly what it will do each time... > > We'd have to follow the already established behavior of the commands, and > there are the man pages to describe what's going on with the verbosity for > each command. In other words, nothing would get changed, just some more > knobs would be added, for those who prefer to have the additional verbosity > enabled. Ok I see. > > Ok so it sounds like you prefer to use "verbose" as the setting key? > > I guess at this point that might make more sense since commit.verbose > > already exists, and existing options could be packed into it like you > > said instead of just true or false. > > It looks like a logical choice to me. > Ok. > > And then my thing here would just be called "command.verbose = > > extended"? > > Yes, that's what I propose. It also looks like a logical choice to me, and > it would leave space for some possible later changes to the > "<command>.verbose = extended" verbosity, without tying it to the tables. > We'd also leave some space that way for even maybe an additional level of > verbosity, be it "<command>.verbose = simple", "<command>.verbose = > graphical" or whatever. > > Perhaps this scheme should also support "<command>.verbose = basic", which > would be an alias for "<command>.verbose = true", for additional clarity. > Sounds good! > > Perhaps it would also be good to nudge the newbies a bit by requesting them > to enable the extended verbosity for each command by hand. That way they > would both learn a bit about the way git configuration works, which they > ultimately can't escape from, and they would be excited to learn new git > commands. Or I at least hope so. :) > Hehe ok, maybe there is room in some hints to notify users of the extended option... > > And it's true that some users might only want the extended (or any > > format) for specific commands. I think a happy medium then is to have > > the command-specific settings like you mention, plus one toplevel > > option that enables a specific type of output format among all commands > > (and overrides the command-specific settings), so that the user can > > choose which they prefer. > > That's something we can consider as an additional configuration option. > That way, users could also enable the basic verbosity for all commands, > which may also be usable. > Cool! > > Any thoughts on what the section in the config for a more general > > setting like this might be named? > > Maybe "core.verbose"? We already have "core.pager", which kind of affects > the way all command outputs look like. Ok! The idea of using "core" came to mind but I wasn't sure if that was more for lower-level settings or more general things. Great. Thanks a lot for all the feedback. Let me doctor up the patch series to take these things into account and submit an RFC v3 :D
On 2023-10-28 17:21, Jacob Stopak wrote: > On Sat, Oct 28, 2023 at 07:55:31AM +0200, Dragan Simic wrote: >>> Basically what I'm asking is if commands that already have a >>> --verbose >>> flag would just get a config setting that does the existing thing by >>> default? >> >> Well, not by default. The default values would remain "false", so >> nothing >> jumps out of nowhere. > > Right, sorry, I worded that poorly. No worries, just wanted to make sure we're on the same page. >> Yes, that's what I propose. It also looks like a logical choice to >> me, and >> it would leave space for some possible later changes to the >> "<command>.verbose = extended" verbosity, without tying it to the >> tables. >> We'd also leave some space that way for even maybe an additional level >> of >> verbosity, be it "<command>.verbose = simple", "<command>.verbose = >> graphical" or whatever. >> >> Perhaps this scheme should also support "<command>.verbose = basic", >> which >> would be an alias for "<command>.verbose = true", for additional >> clarity. >> > Sounds good! I'm glad you agree. >> Perhaps it would also be good to nudge the newbies a bit by requesting >> them >> to enable the extended verbosity for each command by hand. That way >> they >> would both learn a bit about the way git configuration works, which >> they >> ultimately can't escape from, and they would be excited to learn new >> git >> commands. Or I at least hope so. :) >> > Hehe ok, maybe there is room in some hints to notify users of the > extended option... I agree, there should be a well-placed hint, but we'd need to think really well where to place it, so we don't annoy experienced git users too much, while we also inform the less experienced users. >> > Any thoughts on what the section in the config for a more general >> > setting like this might be named? >> >> Maybe "core.verbose"? We already have "core.pager", which kind of >> affects >> the way all command outputs look like. > > Ok! The idea of using "core" came to mind but I wasn't sure if that was > more for lower-level settings or more general things. I also considered the "core" section to be reserved for the very low-level internal things, but having "core.pager" clearly allows other appropriate configuration options to be placed here. > Great. Thanks a lot for all the feedback. Let me doctor up the patch > series to take these things into account and submit an RFC v3 :D Sounds good, thank you. If you agree, I'll go ahead and implement support for a few "<command>.verbose" configuration options during the next week or so, and submit the patches. I'll most probably come to some more important conclusions while implementing that, which I'll relay over, of course.
On Sat, Oct 28, 2023 at 06:20:41PM +0200, Dragan Simic wrote: > > Hehe ok, maybe there is room in some hints to notify users of the > > extended option... > > I agree, there should be a well-placed hint, but we'd need to think really > well where to place it, so we don't annoy experienced git users too much, > while we also inform the less experienced users. Yes, hmm, I wonder if maybe we could add the hint for the extended option only in the case that the user uses the --verbose option either on the command line or via the config setting. Since using the verbose option tells us the user is asking for more details, that might be a good time to inform them of the _even more detailed_ option, but of course that hint could be disabled easily if they preferred the "basic" verbosity. > > > > Any thoughts on what the section in the config for a more general > > > > setting like this might be named? > > > > > > Maybe "core.verbose"? We already have "core.pager", which kind of > > > affects the way all command outputs look like. > > > > Ok! The idea of using "core" came to mind but I wasn't sure if that was > > more for lower-level settings or more general things. > > I also considered the "core" section to be reserved for the very low-level > internal things, but having "core.pager" clearly allows other appropriate > configuration options to be placed here. Ok awesome! > > Great. Thanks a lot for all the feedback. Let me doctor up the patch > > series to take these things into account and submit an RFC v3 :D > > Sounds good, thank you. If you agree, I'll go ahead and implement support > for a few "<command>.verbose" configuration options during the next week or > so, and submit the patches. I'll most probably come to some more important > conclusions while implementing that, which I'll relay over, of course. Yes I agree, that sounds great! Maybe I'll just wait then until seeing your implementation of that before I poke around on mine more. Then I'll apply your patches locally to add my extended option.
On 2023-10-28 19:35, Jacob Stopak wrote: > On Sat, Oct 28, 2023 at 06:20:41PM +0200, Dragan Simic wrote: >> I agree, there should be a well-placed hint, but we'd need to think >> really >> well where to place it, so we don't annoy experienced git users too >> much, >> while we also inform the less experienced users. > > Yes, hmm, I wonder if maybe we could add the hint for the extended > option > only in the case that the user uses the --verbose option either on the > command line or via the config setting. Since using the verbose option > tells us the user is asking for more details, that might be a good time > to inform them of the _even more detailed_ option, but of course that > hint could be disabled easily if they preferred the "basic" verbosity. That's something we can keep thinking about, until we find a good solution. Also, a detailed review of the current logic behind displaying the hints should be performed first, if you agree. >> Sounds good, thank you. If you agree, I'll go ahead and implement >> support >> for a few "<command>.verbose" configuration options during the next >> week or >> so, and submit the patches. I'll most probably come to some more >> important >> conclusions while implementing that, which I'll relay over, of course. > > Yes I agree, that sounds great! Maybe I'll just wait then until seeing > your implementation of that before I poke around on mine more. Then > I'll > apply your patches locally to add my extended option. Great, thanks. I'll start working on the patches tomorrow or so, and I'll get back with any important conclusions or open questions arising from that, so we can discuss them further.
On Sat, Oct 28, 2023 at 07:41:47PM +0200, Dragan Simic wrote: > That's something we can keep thinking about, until we find a good solution. > Also, a detailed review of the current logic behind displaying the hints > should be performed first, if you agree. Yes of course. > > Yes I agree, that sounds great! Maybe I'll just wait then until seeing > > your implementation of that before I poke around on mine more. Then I'll > > apply your patches locally to add my extended option. > > Great, thanks. I'll start working on the patches tomorrow or so, and I'll > get back with any important conclusions or open questions arising from that, > so we can discuss them further. :)
Take into account reviewer feedback by doing several things differently: * Rename this feature (for now) as "noob format mode" (or just "noob mode") instead of the original "--table" verbiage. As pointed out, this no longer ties the name of the setting to it's proposed implementation detail as a table. Noob mode is not necessarily the right name, just a placeholder for now. Unless people like it :D * Instead of manually having to invoke the -t, --table every time this format is to be used, set the config option "status.noob" to true. Although this is logically tied to the status command, there are many commands that produce status output, (and this series adds more), so assume that if the user wants to see the status this way, that it should be enabled whenever the status info is displayed. * When running "git add" and "git restore" while noob mode is enabled, perform the add/restore function as usual, but display the table formatted output with arrows showing how file changes moved around. Displaying the output in this understandable format after each command execution allows the noob to immediately see what they did. Although this series only implements for status, add, and restore, this output format would make sense in other commands like rm, mv, commit, clean, and stash. * Works consistently with commands that already have a --dry-run (-n) option. The dry run shows the exact same output, but doesn't actually do the thing. * If `advice.statusHints` is true, add a table footer with status hints. Shorten these hints so that they are still clear but better fit into a table. Make the hint text yellow to distinguish them. The hints only appear when explicitly running "git status", which helps the user answer the question "what can I do next?". Hints are omitted in "impact" commands like add and restore. Having hints here distracts from the file change moves being showed in the table by arrows. TODO: * "git status" outputs myriad other information depending on the state of the repo, like branch info, merge conflicts, rebase info, bisect, etc. Need to think about how to convey that info with the new setting. * Some commands (like stash) might need more than 3 table columns to display everything clearly. * For destructive commands, think about adding a prompt describing the effect, so the user can confirm before the action is taken. * Fix horrible things in the patch series code. * Probably other things. Play around with it! It's fun! Jacob Stopak (6): status: add noob format from status.noob config status: handle long paths in noob format add: implement noob mode add: set unique color for noob mode arrows restore: implement noob mode status: add advice status hints as table footer Makefile | 2 + builtin/add.c | 47 +++++-- builtin/checkout.c | 46 +++++-- builtin/commit.c | 157 +---------------------- commit.c | 2 + noob.c | 198 +++++++++++++++++++++++++++++ noob.h | 21 ++++ read-cache-ll.h | 10 +- read-cache.c | 41 +++++- table.c | 301 +++++++++++++++++++++++++++++++++++++++++++++ table.h | 6 + wt-status.c | 75 +++++++---- wt-status.h | 6 + 13 files changed, 708 insertions(+), 204 deletions(-) create mode 100644 noob.c create mode 100644 noob.h create mode 100644 table.c create mode 100644 table.h