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

Re: [RFC] Re: Convert 'git blame' to parse_options()

From
Pierre Habouzit <madcoder@debian.org>
Date
Jun 23, 2008, 21:47 UTC
Message-ID
<20080623214758.GF13395@artemis.madism.org>
In-Reply-To
<alpine.LFD.1.10.0806231425270.2926@woody.linux-foundation.org>
On Mon, Jun 23, 2008 at 09:26:39PM +0000, Linus Torvalds wrote:
Show 15 quoted lines
> 
> 
> On Mon, 23 Jun 2008, Pierre Habouzit wrote:
> > 
> >   Let's see if I can catch it elegantly.
> 
> No.
> 
> Look at builtin-blame.c.
> 
> THEN get back to me.
> 
> Trust me, you need what I wrote. Something that parses all the options in 
> one go, and ignores the ones it cannot parse, because a TOTALLY DIFFERENT 
> function than the caller will call it!

Well I really believe that with an incremental parse_revisions (I have sent the patch to split {init,parse,setup}_revisions already) instead of the 'do all at once' version, you can write the code in builtin-blame in one pass exactly with the series I wrote.

> Why is that so hard to accept? Especially since I already wrote the code 
> and sent it out?

I don't find it "hard to accept", I just don't like the idea because it's broken wrt some parse-options mechanisms that I like a lot, and would be sad to see broken, and that with a little work can be overcomed. Note that builtin-blame is contains probably the most involved option parser in git.git, and isn't really what one could call representative of what awaits us on the path of migrating git.git to parse-options fully.

I don't expect it to be easy to migrate at all. I do believe your code works too, it's obvious to see it does actually. But it could be made better, with real code that I will provide, just not tonight because I'm exhausted.

Note that an incremental parse_revisions/parse_diff_opts/.. are a precodition to many CLI parsers conversions anyways, so if the task seems a bit exagerated for the sake of git-blame only, it actually helps for dozens of other commands, where the conversion will just be trivial.

I fully understand you frustration wrt the poor handling of the command line arguments in many git commands. Believe me I really do. I know I haven't been active on this front for something like 6 months, but I'm sadly not payed to work on git.git ;p Though things are moving right now, so why don't we wait another week to see what other propose ?

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
Previous: Linus TorvaldsNext: Junio C Hamano
Message 32 of 82 in “Convert 'git blame' to parse_options()”
  1. Linus TorvaldsJun 23, 2008
  2. Junio C HamanoJun 23, 2008
  3. Johannes SchindelinJun 23, 2008
  4. [RFC] Re: Convert 'git blame' to parse_options()Pierre Habouzit, Jun 23, 2008
  5. Johannes SchindelinJun 23, 2008
  6. Pierre HabouzitJun 23, 2008
  7. Johannes SchindelinJun 23, 2008
  8. Linus TorvaldsJun 23, 2008
  9. Jeff KingJun 23, 2008
  10. Linus TorvaldsJun 23, 2008
  11. Jeff KingJun 23, 2008
  12. Linus TorvaldsJun 23, 2008
  13. Jeff KingJun 23, 2008
  14. Linus TorvaldsJun 23, 2008
  15. Linus TorvaldsJun 23, 2008
  16. Jeff KingJun 23, 2008
  17. Linus TorvaldsJun 23, 2008
  18. Linus TorvaldsJun 23, 2008
  19. Pierre HabouzitJun 23, 2008
  20. parse-opt: have parse_options_{start,end}.Pierre Habouzit, Jun 23, 2008
  21. parse-opt: Export a non NORETURN usage dumper.Pierre Habouzit, Jun 23, 2008
  22. parse-opt: create parse_options_step.Pierre Habouzit, Jun 23, 2008
  23. parse-opt: do not pring errors on unknown options, return -2 intead.Pierre Habouzit, Jun 23, 2008
  24. parse-opt: fake short strings for callers to believe in.Pierre Habouzit, Jun 23, 2008
  25. Junio C HamanoJun 23, 2008
  26. Pierre HabouzitJun 23, 2008
  27. Pierre HabouzitJun 23, 2008
  28. Junio C HamanoJun 23, 2008
  29. Pierre HabouzitJun 23, 2008
  30. Linus TorvaldsJun 23, 2008
  31. Linus TorvaldsJun 23, 2008
  32. Pierre HabouzitJun 23, 2008
  33. Junio C HamanoJun 23, 2008
  34. Pierre HabouzitJun 23, 2008
  35. Pierre HabouzitJun 23, 2008
  36. Junio C HamanoJun 23, 2008
  37. Pierre HabouzitJun 23, 2008
  38. Linus TorvaldsJun 23, 2008
  39. Junio C HamanoJun 23, 2008
  40. Pierre HabouzitJun 24, 2008
  41. Jeff KingJun 24, 2008
  42. Jeff KingJun 23, 2008
  43. Pierre HabouzitJun 23, 2008
  44. Linus TorvaldsJun 23, 2008
  45. Jeff KingJun 24, 2008
  46. Linus TorvaldsJun 24, 2008
  47. Johannes SchindelinJun 24, 2008
  48. Jeff KingJun 24, 2008
  49. Linus TorvaldsJun 24, 2008
  50. Jeff KingJun 24, 2008
  51. Junio C HamanoJun 24, 2008
  52. Pierre HabouzitJun 24, 2008
  53. Linus TorvaldsJun 24, 2008
  54. Pierre HabouzitJun 24, 2008
  55. Pierre HabouzitJun 24, 2008
  56. Johannes SixtJun 25, 2008
  57. Johannes SchindelinJun 23, 2008
  58. Linus TorvaldsJun 23, 2008
  59. Johannes SchindelinJun 23, 2008
  60. Jeff KingJun 23, 2008
  61. Johannes SchindelinJun 23, 2008
  62. Pierre HabouzitJun 23, 2008
  63. Linus TorvaldsJun 23, 2008
  64. Making parse-opt incremental, reworked seriesPierre Habouzit, Jun 24, 2008
  65. 1/7 parse-opt: have parse_options_{start,end}.Pierre Habouzit, Jun 24, 2008
  66. 2/7 parse-opt: Export a non NORETURN usage dumper.Pierre Habouzit, Jun 24, 2008
  67. 3/7 parse-opt: create parse_options_step.Pierre Habouzit, Jun 24, 2008
  68. 4/7 parse-opt: do not pring errors on unknown options, return -2 intead.Pierre Habouzit, Jun 24, 2008
  69. 5/7 parse-opt: fake short strings for callers to believe in.Pierre Habouzit, Jun 24, 2008
  70. 6/7 parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.Pierre Habouzit, Jun 24, 2008
  71. 7/7 Migrate git-blame to parse-option partially.Pierre Habouzit, Jun 24, 2008
  72. Pierre HabouzitJun 24, 2008
  73. Linus TorvaldsJun 24, 2008
  74. Pierre HabouzitJun 24, 2008
  75. Pierre HabouzitJun 24, 2008
  76. Linus TorvaldsJun 24, 2008
  77. Pierre HabouzitJun 24, 2008
  78. Andreas EricssonJun 25, 2008
  79. parse-opt: fake short strings for callers to believe in.Pierre Habouzit, Jun 24, 2008
  80. Pierre HabouzitJun 26, 2008
  81. Junio C HamanoJun 26, 2008
  82. Pierre HabouzitJun 26, 2008

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.