Russ Dill <russ.dill@xxxxxxxxx> wrote: > On Wed, Apr 23, 2008 at 4:13 PM, Haakon Riiser <haakon.riiser@xxxxxxxxxx> 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. -- 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
