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

Re: [PATCH 1/4] notes: print note blob to stdout directly

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 6, 2024, 17:52 UTC
Message-ID
<xmqqy1bxiiop.fsf@gitster.g>
In-Reply-To
<CA+CvcKTtcHCCKucQ0h1dnaDAMNfErJ+a1CXEVi=ZE5dv57Tb3A@mail.gmail.com>
Maarten Bosmans <mkbosmans@gmail.com> writes:
Show 5 quoted lines
>> I am not sure if we want to accept an approach that feels somewhat
>> narrow/short sighted, like this patch.  When "git show" learns an
>> improved way to show blob objects, who will update the code this
>> patch touches to teach it to use the same improved way to show the
>> notes?

Another thing I forgot to mention was that I suspected the use of "git show" was so that we can deal with notes trees whose leaves are *not* blob objects. As our "git notes" machinery, including how the initial contents are populated with "git notes add" and how existing notes on the same object are merged, all assume and depend on that the leaves are blobs, we can say "we'll just dump to stdout with write_in_full()", but who knows what kind of custom crap random third-party tools and IDEs try to use notes trees to store.

Even if we limit ourselves to blobs, they may not be suitable to be dumped to tty (or a pager, for that matter), and I can see how textconv could be used as a way out ("detect that the notes payload is an image and spawn display" kind of hack in a repository full of images and notes used to store thumbnails, perhaps).

> That is also a cool idea. That would probably use the functionality of
> the cat-file batch mode, right?

Not really. I was hoping that "git show" that can take multiple objects from its command line would directly be used, or with a new option that gives a separator between these objects.

Perhaps we want a new option, e.g., "git notes show --text" that passes the contents of the leaf blob object to write_in_full(), bypassing all the things "git show" does, while in a rare case when the leaf we find is not a blob to invoke "git show". That might be a safe approach to move forward, if we wanted to do this.

Previous: Maarten BosmansNext: Jeff King
Message 7 of 36 in “Speed up git-notes show”
  1. 0/4 Speed up git-notes showMaarten Bosmans, Feb 5, 2024
  2. 2/4 notes: use exisisting function stream_blob_to_fdMaarten Bosmans, Feb 5, 2024
  3. Eric SunshineFeb 5, 2024
  4. 1/4 notes: print note blob to stdout directlyMaarten Bosmans, Feb 5, 2024
  5. Junio C HamanoFeb 6, 2024
  6. Maarten BosmansFeb 6, 2024
  7. Junio C HamanoFeb 6, 2024
  8. Jeff KingFeb 13, 2024
  9. Junio C HamanoFeb 13, 2024
  10. Jeff KingFeb 15, 2024
  11. Junio C HamanoFeb 16, 2024
  12. Jeff KingFeb 17, 2024
  13. Junio C HamanoFeb 17, 2024
  14. Jeff KingFeb 17, 2024
  15. Maarten BosmansFeb 15, 2024
  16. Jeff KingFeb 15, 2024
  17. Maarten BosmansFeb 17, 2024
  18. Jeff KingFeb 20, 2024
  19. Maarten BosmansFeb 15, 2024
  20. Kristoffer HaugsbakkFeb 6, 2024
  21. 3/4 notes: do not clean up right before calling die()Maarten Bosmans, Feb 5, 2024
  22. 4/4 notes: use strbuf_attach to take ownership of the object contentsMaarten Bosmans, Feb 5, 2024
  23. Kristoffer HaugsbakkFeb 6, 2024
  24. Maarten BosmansFeb 6, 2024
  25. 0/5 Speed up git-notes showMaarten Bosmans, Feb 18, 2024
  26. 1/5 log: Move show_blob_object() to log.cMaarten Bosmans, Feb 18, 2024
  27. Junio C HamanoFeb 20, 2024
  28. Jeff KingFeb 20, 2024
  29. Junio C HamanoFeb 20, 2024
  30. Maarten BosmansFeb 20, 2024
  31. 3/5 notes: use existing function stream_blob_to_fdMaarten Bosmans, Feb 18, 2024
  32. 2/5 notes: avoid launching a child process to show a note blobMaarten Bosmans, Feb 18, 2024
  33. 5/5 notes: use strbuf_attach to take ownership of the object contentsMaarten Bosmans, Feb 18, 2024
  34. Jeff KingFeb 20, 2024
  35. Maarten BosmansFeb 20, 2024
  36. 4/5 notes: do not clean up right before calling die()Maarten Bosmans, Feb 18, 2024

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.