From: Martin von Zweigbergk <martinvonz@google.com>
To: git@vger.kernel.org
Cc: Martin von Zweigbergk <martinvonz@google.com>
Subject: [PATCH] docs: clarify that refs/notes/ do not keep the attached objects alive
Date: Wed, 10 Feb 2021 16:00:21 -0800 [thread overview]
Message-ID: <e7fde2369495f32c7aa88c7b6b74ebee1a1bed24.1613000292.git.martinvonz@google.com> (raw)
`git help gc` contains this snippet:
"[...] it will keep [..] objects referenced by the index,
remote-tracking branches, notes saved by git notes under refs/notes/"
I had interpreted that as saying that the objects that notes were
attached to are kept, but that is not the case. Let's clarify the
documentation by moving out the part about git notes to a separate
sentence.
---
Documentation/git-gc.txt | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 0c114ad1ca..52824269a8 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -117,12 +117,14 @@ NOTES
'git gc' tries very hard not to delete objects that are referenced
anywhere in your repository. In particular, it will keep not only
objects referenced by your current set of branches and tags, but also
-objects referenced by the index, remote-tracking branches, notes saved
-by 'git notes' under refs/notes/, reflogs (which may reference commits
-in branches that were later amended or rewound), and anything else in
-the refs/* namespace. If you are expecting some objects to be deleted
-and they aren't, check all of those locations and decide whether it
-makes sense in your case to remove those references.
+objects referenced by the index, remote-tracking branches, reflogs
+(which may reference commits in branches that were later amended or
+rewound), and anything else in the refs/* namespace. Notes saved by
+'git notes' under refs/notes/ will be kept, but the objects (typically
+commits) they are attached to will not be. If you are expecting some
+objects to be deleted and they aren't, check all of those locations
+and decide whether it makes sense in your case to remove those
+references.
On the other hand, when 'git gc' runs concurrently with another process,
there is a risk of it deleting an object that the other process is using
--
2.30.0.478.g8a0d178c01-goog
next reply other threads:[~2021-02-11 0:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-11 0:00 Martin von Zweigbergk [this message]
2021-02-11 0:35 ` [PATCH] docs: clarify that refs/notes/ do not keep the attached objects alive 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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e7fde2369495f32c7aa88c7b6b74ebee1a1bed24.1613000292.git.martinvonz@google.com \
--to=martinvonz@google.com \
--cc=git@vger.kernel.org \
/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.
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 NNTP newsgroup(s).