git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Avery Pennarun <apenwarr@gmail.com>,
	Johannes Sixt <j.sixt@viscovery.net>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: git-gc doesn't clean up leftover objects after git-filter-branch unless you clone first
Date: Wed, 23 Apr 2008 21:28:36 -0400	[thread overview]
Message-ID: <20080424012836.GA30812@sigill.intra.peff.net> (raw)
In-Reply-To: <20080423221316.GE30057@sigill.intra.peff.net>

On Wed, Apr 23, 2008 at 06:13:16PM -0400, Jeff King wrote:

> > - Teach people that leftover cruft is nothing to worry about.
> 
> But it _is_ something to worry about in some particular situations. For
> run-of-the-mill rebasing, sure, ignore it. But this question usually
> comes up because the user did something like:

OK, maybe I am wrong. Within a few hours of me posting this, somebody
starts a new thread with a toy example wondering why git-gc didn't clean
up an --amended commit.

I don't know the best way to teach people about this (short of using a
big stick, of course), but maybe something like this would help a
little:

-- >8 --
doc/git-gc: add a note about what is collected

It seems to be a FAQ that people try running git-gc, and
then get puzzled about why the size of their .git directory
didn't change. This note mentions the reasons why things
might unexpectedly get kept.

Signed-off-by: Jeff King <peff@peff.net>
---
 Documentation/git-gc.txt |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index d424a4e..9a4b62e 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -104,6 +104,21 @@ The optional configuration variable 'gc.pruneExpire' controls how old
 the unreferenced loose objects have to be before they are pruned.  The
 default is "2 weeks ago".
 
+
+Notes
+-----
+
+git-gc tries very hard to be safe about the garbage it collects. 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, refs saved by linkgit:git-filter-branch[1] in
+refs/original/, or reflogs (which may references commits in branches
+that were later amended or rewound).
+
+If you are expecting some objects to be collected and it isn't, check
+all of those locations and decide whether it makes sense in your case to
+remove those references.
+
 See Also
 --------
 linkgit:git-prune[1]
-- 
1.5.5.1.143.ge2bb9

  reply	other threads:[~2008-04-24  1:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-23 15:41 git-gc doesn't clean up leftover objects after git-filter-branch unless you clone first Avery Pennarun
2008-04-23 17:00 ` Junio C Hamano
2008-04-23 18:36   ` Avery Pennarun
2008-04-23 22:13   ` Jeff King
2008-04-24  1:28     ` Jeff King [this message]
2008-04-24 15:43       ` Avery Pennarun
2008-04-24 16:14         ` Jeff King
2008-04-24 16:59           ` Avery Pennarun
2008-04-29 20:45             ` [PATCH] Documentation: point git-prune users to git-gc Jeff King
2008-04-29 22:05               ` Junio C Hamano
2008-04-29 23:19                 ` Jeff King
2008-04-30  1:01                   ` 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=20080424012836.GA30812@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=apenwarr@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j.sixt@viscovery.net \
    /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).