git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Martin von Zweigbergk <martinvonz@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] docs: clarify that refs/notes/ do not keep the attached objects alive
Date: Wed, 10 Feb 2021 21:38:27 -1000	[thread overview]
Message-ID: <CAESOdVCYceVgF4B0f--yjheS+FijX-GJWUYjfgz1tRrL7kU+yA@mail.gmail.com> (raw)
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:
>
> 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).

  reply	other threads:[~2021-02-11  7:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-11  0:00 [PATCH] docs: clarify that refs/notes/ do not keep the attached objects alive Martin von Zweigbergk
2021-02-11  0:35 ` Junio C Hamano
2021-02-11  7:14   ` Martin von Zweigbergk
2021-02-11  7:30     ` Junio C Hamano
2021-02-11  7:38       ` Martin von Zweigbergk [this message]
2021-02-11  7:18 ` [PATCH v2] " Martin von Zweigbergk
2021-02-11  7:34   ` Junio C Hamano
2021-02-11  7:36     ` Martin von Zweigbergk
2021-02-11  7:39 ` [PATCH v3] " Martin von Zweigbergk
2021-02-11  7:43   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAESOdVCYceVgF4B0f--yjheS+FijX-GJWUYjfgz1tRrL7kU+yA@mail.gmail.com \
    --to=martinvonz@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).