Martin von Zweigbergk <martinvonz@xxxxxxxxxx> writes: > `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. > > Signed-off-by: Martin von Zweigbergk <martinvonz@xxxxxxxxxx> > --- > Documentation/git-gc.txt | 14 ++++++++------ > 1 file changed, 8 insertions(+), 6 deletions(-) Thanks. Will replace and queue. > diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt > index 0c114ad1ca..853967dea0 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. Note that a note > +(of the kind created by 'git notes') attached to an object does not > +contribute in keeping the object alive. 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
