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@xxxxxxxx> --- 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
