Re: Cleaning the .git directory with gc

["Shawn O. Pearce" <spearce@spearce.org>]

Russ Dill <russ.dill@gmail.com> wrote:
> On Wed, Apr 23, 2008 at 4:13 PM, Haakon Riiser <haakon.riiser@fys.uio.no> wrote:
> > I've recently started using git, and while experimenting with
> >  git commit --amend, I noticed that git gc does not do what I
> >  expected.  Example:
> 
> Thats a lot of work without first reading the man page:
> 
>        --prune
>            Usually git-gc packs refs, expires old reflog entries, packs loose
>            objects, and removes old rerere records. Removal of unreferenced
>            loose objects is an unsafe operation while other git operations are
>            in progress, so it is not done by default. Pass this option if you
>            want it, and only when you know nobody else is creating new objects
>            in the repository at the same time (e.g. never use this option in a
>            cron script).

But even with `git gc --prune` the old commit object will still
be in your repository.

Why?  Both HEAD and your branch's reflog have a reference to the
old commit.  And those will remain in there for 90 days by default,
so that you could always go back and get that if you _really_
had to recover it.  Take a look with `git reflog show HEAD`
or `git log -g` and you'll see what I mean.

A commit is peanuts when it comes to disk space.  Don't worry
about it.  After a lot of amends and such you will be carrying
around only a few extra MBs.  In return for those few extra MBs
you are always able to recovery anything, up to 3 months back.

If you _really_ need to whack all of that away, make a clone
and then discard the old one, e.g.:

	git clone file://`pwd`/old_proj new_proj

Note you need to use the file:// URI syntax to prevent Git from
just hardlinking everything.  It takes a little longer, but the
resulting new_proj will be cruft free.

-- 
Shawn.