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

Re: [PATCH] docs: clarify that refs/notes/ do not keep the attached objects alive

From
Martin von Zweigbergk <martinvonz@google.com>
Date
Feb 11, 2021, 07:38 UTC
Message-ID
<CAESOdVCYceVgF4B0f--yjheS+FijX-GJWUYjfgz1tRrL7kU+yA@mail.gmail.com>
In-Reply-To
<xmqqeehnysbv.fsf@gitster.c.googlers.com>
On Wed, Feb 10, 2021 at 9:30 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 20 quoted lines
>
> Martin von Zweigbergk <martinvonz@google.com> writes:
>
> > Good point. You dropped the bit about the notes (texts) being kept
> > alive. I don't know if you did that intentionally are not.
>
> Yes, I did it on purpose, because it is just one of the things that
> can be reached from refs/, but we shouldn't write our document for
> those like me, who know what notes and other things in Git are.
>
> > I initially
> > thought that we should keep that bit, but it's probably not actually
> > very useful information. Users probably don't have large amounts of
> > information stored in notes, so they probably don't care whether notes
> > text is kept, especially since there's no good way of pruning the
> > notes.
>
> I am not sure if I agree with any part of the above.  End-user data
> is precious no matter the volume, and we keep notes by making them
> reachable from refs in the refs/notes/ hierarchy.

Sorry, I forgot to qualify that whole paragraph with something like "Regarding notes attached to unreachable commits: ". Users will obviously not want to lose notes about reachable commits and they won't. So the only remaining concern in my mind was whether they might care about it because they *want* to save the space that the note used. Makes more sense then?

> I am not sure what qualifies, in your eyes, "good" way, but "git
> notes prune" is a good way to remove notes that are attached to
> objects that have already been pruned away.

My paragraph above probably clarifies (that I was thinking about saving the space used by notes, which I don't think `git notes prune` helps with).

Previous: Junio C HamanoNext: Martin von Zweigbergk
Message 5 of 10 in “docs: clarify that refs/notes/ do not keep the attached objects alive”
  1. docs: clarify that refs/notes/ do not keep the attached objects aliveMartin von Zweigbergk, Feb 11, 2021
  2. Junio C HamanoFeb 11, 2021
  3. Martin von ZweigbergkFeb 11, 2021
  4. Junio C HamanoFeb 11, 2021
  5. Martin von ZweigbergkFeb 11, 2021
  6. docs: clarify that refs/notes/ do not keep the attached objects aliveMartin von Zweigbergk, Feb 11, 2021
  7. Junio C HamanoFeb 11, 2021
  8. Martin von ZweigbergkFeb 11, 2021
  9. docs: clarify that refs/notes/ do not keep the attached objects aliveMartin von Zweigbergk, Feb 11, 2021
  10. Junio C HamanoFeb 11, 2021

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.