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

Re: [PATCH v10 6/9] ls-tree.c: support --object-only option for "git-ls-tree"

From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date
Feb 4, 2022, 12:58 UTC
Message-ID
<220204.865ypu3hqm.gmgdl@evledraar.gmail.com>
In-Reply-To
<CADMgQSQzqW9m1XM7_EE09eBhkheMj6QCZ+pVjtHWW2HY=u_o2g@mail.gmail.com>
On Tue, Jan 18 2022, Teng Long wrote:
Show 29 quoted lines
> On Fri, Jan 14, 2022 at 7:59 PM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>
>> Yes, you get the functionality you need with a simple alias of
>> --format='%(objectname)' to --object-name (or whatever), so the only
>> reason to carry the extra code is for optimization.
>>
>> I wonder if the extra difference in performance is still something you
>> care about, or if just the --format implementation would be OK.
>>
>> But in any case, starting with a simpler implementation and testing it
>> makes the progression easier to reason about.
>
> Actually, at first, I wanted to achieve this in a simple way, as the
> "--object-only" implementation.
>
> With the discussion in the community, I think both of them can achieve
> this purpose. "--object-only" is more intuitive, while "--format "is
> more flexible.
> For example, if the terminal supports automatic completion, the function of
> this option can be clearly known with typing TAB and lower costs of use and
> understanding. "--format"  also works, but maybe have to check the help
> document to see if there are fields that support the same purpose.
>
> Because the community had a different opinion about it. Junio, might prefer
> an "--object-only" approach, if I understand the context correctly.
>
> So I have some inclination to support both. However, I can accept that only
> "--format" is supported.

I'm only talking about how it's implemented internally, not whether we have an --object-only option in the UI. I think it's good to have the option for completion etc.

I.e. in my RFC implementation of it here it's just a trivial wrapper around specifying a --format: https://lore.kernel.org/git/RFC-patch-7.7-5e34df4f8dd-20211217T131635Z-avarab@gmail.com/; Implementing it is 6 lines of trivial C code boilerplate.

But when you picked that up & ran with it you ended up carrying your original implementation: https://lore.kernel.org/git/e0274f079a7d381b9a936bfcd53bad64167c18b8.1641440700.git.dyroneteng@gmail.com/

I'm not saying we shouldn't have that, but that in any case a sequence of:
 1. Add a --format option
 2. Add a --object-only alias for a --format (what my RFC 7/7 does)
 3. Add a custom more optimized --object-only implementation

Would make the patch progression much easier to read, and we'd consider the correctness of --object-only (1 and 2) separate from the optimization question (3).

But maybe we won't need (3) at all in the end, i.e. is (1 and 2) fast enough for it not to matter (I think probably "yes", but I don't have a strong opinion on that).

> So in the next patch, I hope to do some refactoring of the commit to support
> "--object-only" as the top commit. If in the end, we decide that "--format" is
> enough, we can discard the top "--object-only" commit.
*nod*, now that I read ahead I think you pretty much agree with that plan :)
> I know you guys currently are busy on the new 2.35 release, so a later reply
> is OK.
Now would be a good time :)

I was reminded of this because Junio's proposed it for next at https://lore.kernel.org/git/xmqqr18jnr2t.fsf@gitster.g/

I think per the above & other replies of mine (including not matters of code arrangement opinion, but e.g. the doc formatting bug) we'll need at least one more re-roll of this. Thanks for sticking with this & working on this!

I'll indicate that in a reply to that "What's Cooking" report.
Previous: Teng LongNext: Teng Long
Message 66 of 74 in “ls-tree: "--object-only" and "--format" opts”
  1. 0/8 ls-tree: "--object-only" and "--format" optsTeng Long, Jan 1, 2022
  2. 1/8 ls-tree: remove commented-out codeTeng Long, Jan 1, 2022
  3. 2/8 ls-tree: add missing braces to "else" armsTeng Long, Jan 1, 2022
  4. 3/8 ls-tree: use "enum object_type", not {blob,tree,commit}_typeTeng Long, Jan 1, 2022
  5. 4/8 ls-tree: use "size_t", not "int" for "struct strbuf"'s "len"Teng Long, Jan 1, 2022
  6. 5/8 ls-tree: split up the "init" part of show_tree()Teng Long, Jan 1, 2022
  7. Junio C HamanoJan 4, 2022
  8. Teng LongJan 4, 2022
  9. 6/8 ls-tree.c: support --object-only option for "git-ls-tree"Teng Long, Jan 1, 2022
  10. Junio C HamanoJan 4, 2022
  11. Teng LongJan 4, 2022
  12. 7/8 ls-tree.c: introduce struct "shown_data"Teng Long, Jan 1, 2022
  13. Junio C HamanoJan 3, 2022
  14. Teng LongJan 4, 2022
  15. 8/8 ls-tree.c: introduce "--format" optionTeng Long, Jan 1, 2022
  16. Johannes SchindelinJan 4, 2022
  17. Johannes SchindelinJan 4, 2022
  18. Teng LongJan 5, 2022
  19. Teng LongJan 5, 2022
  20. Johannes SchindelinJan 5, 2022
  21. Teng LongJan 5, 2022
  22. 0/9 ls-tree.c: introduce "--format" optionTeng Long, Jan 6, 2022
  23. 1/9 ls-tree: remove commented-out codeTeng Long, Jan 6, 2022
  24. 2/9 ls-tree: add missing braces to "else" armsTeng Long, Jan 6, 2022
  25. 3/9 ls-tree: use "enum object_type", not {blob,tree,commit}_typeTeng Long, Jan 6, 2022
  26. 4/9 ls-tree: use "size_t", not "int" for "struct strbuf"'s "len"Teng Long, Jan 6, 2022
  27. 5/9 ls-tree: optimize naming and handling of "return" in show_tree()Teng Long, Jan 6, 2022
  28. Junio C HamanoJan 6, 2022
  29. Teng LongJan 11, 2022
  30. 6/9 ls-tree.c: support --object-only option for "git-ls-tree"Teng Long, Jan 6, 2022
  31. 7/9 ls-tree.c: introduce struct "show_tree_data"Teng Long, Jan 6, 2022
  32. 8/9 ls-tree.c: introduce "--format" optionTeng Long, Jan 6, 2022
  33. Martin ÅgrenJan 10, 2022
  34. Teng LongJan 11, 2022
  35. 9/9 cocci: allow padding with `strbuf_addf()`Teng Long, Jan 6, 2022
  36. Johannes SchindelinJan 7, 2022
  37. Teng LongJan 10, 2022
  38. Johannes SchindelinJan 10, 2022
  39. Teng LongJan 10, 2022
  40. Junio C HamanoJan 10, 2022
  41. Ævar Arnfjörð BjarmasonJan 10, 2022
  42. Junio C HamanoJan 10, 2022
  43. Ævar Arnfjörð BjarmasonJan 10, 2022
  44. Teng LongJan 11, 2022
  45. Taylor BlauJan 11, 2022
  46. René ScharfeJan 11, 2022
  47. Taylor BlauJan 11, 2022
  48. Teng LongJan 13, 2022
  49. Ævar Arnfjörð BjarmasonJan 11, 2022
  50. Teng LongJan 13, 2022
  51. Teng LongJan 13, 2022
  52. 0/9 ls-tree: "--object-only" and "--format" optsTeng Long, Jan 13, 2022
  53. 1/9 ls-tree: remove commented-out codeTeng Long, Jan 13, 2022
  54. 2/9 ls-tree: add missing braces to "else" armsTeng Long, Jan 13, 2022
  55. 3/9 ls-tree: use "enum object_type", not {blob,tree,commit}_typeTeng Long, Jan 13, 2022
  56. 4/9 ls-tree: use "size_t", not "int" for "struct strbuf"'s "len"Teng Long, Jan 13, 2022
  57. 5/9 ls-tree: optimize naming and handling of "return" in show_tree()Teng Long, Jan 13, 2022
  58. Ævar Arnfjörð BjarmasonJan 13, 2022
  59. Teng LongJan 14, 2022
  60. Ævar Arnfjörð BjarmasonJan 14, 2022
  61. 6/9 ls-tree.c: support --object-only option for "git-ls-tree"Teng Long, Jan 13, 2022
  62. Ævar Arnfjörð BjarmasonJan 13, 2022
  63. Teng LongJan 14, 2022
  64. Ævar Arnfjörð BjarmasonJan 14, 2022
  65. Teng LongJan 18, 2022
  66. Ævar Arnfjörð BjarmasonFeb 4, 2022
  67. Teng LongFeb 7, 2022
  68. 7/9 ls-tree.c: introduce struct "show_tree_data"Teng Long, Jan 13, 2022
  69. Ævar Arnfjörð BjarmasonJan 13, 2022
  70. Teng LongJan 14, 2022
  71. 8/9 cocci: allow padding with `strbuf_addf()`Teng Long, Jan 13, 2022
  72. 9/9 ls-tree.c: introduce "--format" optionTeng Long, Jan 13, 2022
  73. Ævar Arnfjörð BjarmasonJan 13, 2022
  74. Teng LongJan 18, 2022

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.