Re: Cleaning the .git directory with gc
- From
Shawn O. Pearce <spearce@spearce.org>
- Date
- Apr 24, 2008, 00:50 UTC
- Message-ID
- <20080424005013.GP29771@spearce.org>
- In-Reply-To
- <f9d2a5e10804231709v1d7e426fwf68b3d316a15081a@mail.gmail.com>
Russ Dill <russ.dill@gmail.com> wrote:
Show 15 quoted lines
> 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.