git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC PATCH v2 0/6] Noobify format for status, add, restore

From
Jacob Stopak <jacob@initialcommit.io>
Date
Oct 28, 2023, 15:21 UTC
Message-ID
<ZT0m68HWZS/tDGtH.jacob@initialcommit.io>
In-Reply-To
<2a0ba4c8e96cb7d2ea66dd1e78cdd39c@manjaro.org>
On Sat, Oct 28, 2023 at 07:55:31AM +0200, Dragan Simic wrote:
Show 6 quoted lines
> > 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!
Show 6 quoted lines
> > 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.
Show 10 quoted lines
> > 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.
Show 7 quoted lines
> > 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.
Show 13 quoted lines
> > 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!
Show 7 quoted lines
> 
> 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...

Show 11 quoted lines
> > 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!
Show 5 quoted lines
> > 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

Previous: Dragan SimicNext: Dragan Simic
Message 58 of 62 in “Introduce -t, --table for status/add commands”
  1. 0/5 Introduce -t, --table for status/add commandsJacob Stopak, Oct 20, 2023
  2. 1/5 status: introduce -t, --table flagJacob Stopak, Oct 20, 2023
  3. 2/5 status: handle long paths with -t, --table flagJacob Stopak, Oct 20, 2023
  4. 3/5 status: add advice arg for -t, --table flagJacob Stopak, Oct 20, 2023
  5. 5/5 add: set unique color for -t, --table arrowsJacob Stopak, Oct 20, 2023
  6. 4/5 add: add -t, --table flag for visual dry runsJacob Stopak, Oct 20, 2023
  7. Dragan SimicOct 20, 2023
  8. Jacob StopakOct 20, 2023
  9. Dragan SimicOct 20, 2023
  10. Junio C HamanoOct 20, 2023
  11. Jacob StopakOct 22, 2023
  12. Dragan SimicOct 22, 2023
  13. Jacob StopakOct 22, 2023
  14. Dragan SimicOct 22, 2023
  15. Oswald BuddenhagenOct 22, 2023
  16. Dragan SimicOct 22, 2023
  17. Oswald BuddenhagenOct 23, 2023
  18. Dragan SimicOct 23, 2023
  19. Jacob StopakOct 23, 2023
  20. Dragan SimicOct 23, 2023
  21. Oswald BuddenhagenOct 23, 2023
  22. Jacob StopakOct 23, 2023
  23. Oswald BuddenhagenOct 23, 2023
  24. Dragan SimicOct 23, 2023
  25. Oswald BuddenhagenOct 23, 2023
  26. Dragan SimicOct 23, 2023
  27. Jacob StopakOct 23, 2023
  28. Dragan SimicOct 24, 2023
  29. Junio C HamanoOct 24, 2023
  30. Dragan SimicOct 24, 2023
  31. Dragan SimicJan 5, 2024
  32. Jacob StopakJan 6, 2024
  33. Dragan SimicJan 6, 2024
  34. Dragan SimicOct 23, 2023
  35. Junio C HamanoOct 23, 2023
  36. Dragan SimicOct 23, 2023
  37. Oswald BuddenhagenOct 23, 2023
  38. Dragan SimicOct 23, 2023
  39. Jacob StopakOct 23, 2023
  40. Dragan SimicOct 23, 2023
  41. Jacob StopakOct 23, 2023
  42. Jacob StopakOct 22, 2023
  43. 0/6 Noobify format for status, add, restoreJacob Stopak, Oct 26, 2023
  44. 1/6 status: add noob format from status.noob configJacob Stopak, Oct 26, 2023
  45. Junio C HamanoOct 30, 2023
  46. Dragan SimicOct 30, 2023
  47. Jacob StopakOct 30, 2023
  48. 2/6 status: handle long paths in noob formatJacob Stopak, Oct 26, 2023
  49. 4/6 add: set unique color for noob mode arrowsJacob Stopak, Oct 26, 2023
  50. 3/6 add: implement noob modeJacob Stopak, Oct 26, 2023
  51. 5/6 restore: implement noob modeJacob Stopak, Oct 26, 2023
  52. 6/6 status: add advice status hints as table footerJacob Stopak, Oct 26, 2023
  53. Dragan SimicOct 27, 2023
  54. Jacob StopakOct 27, 2023
  55. Dragan SimicOct 28, 2023
  56. Jacob StopakOct 28, 2023
  57. Dragan SimicOct 28, 2023
  58. Jacob StopakOct 28, 2023
  59. Dragan SimicOct 28, 2023
  60. Jacob StopakOct 28, 2023
  61. Dragan SimicOct 28, 2023
  62. Jacob StopakOct 28, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.