Re: "git gc" doesn't seem to remove loose objects any more
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Dec 15, 2008, 17:07 UTC
- Message-ID
- <m3vdtlcqp6.fsf@localhost.localdomain>
- In-Reply-To
- <20081215155610.GA11502@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> On Mon, Dec 15, 2008 at 03:08:34PM +0100, Björn Steinbrink wrote:
Show 23 quoted lines
> > To clarify that a bit more: git gc keeps unreachable objects unpacked, > > so that git prune can drop them. And git gc invokes git prune so that > > only unreachable objects older than 2 weeks are dropped. > > To be even more explicit, "git gc" will **unpack** objects that have > become unreachable and were currently in packs. As a result, the > amount of disk space used by a git repository can actually go **up** > dramatically after a "git gc" operation, which could be surprising for > someone who is running close to full on their filesystem, deletes a > number of branches from a tracking repository, and then does a "git > gc" may get a very unpleasant surprise. > > A really good repository which shows this is linux-next, since it is > constantly getting rewound, and old branches are reserved via a tag > such as next-20081204. If you update the your local copy of the > linux-next repository every day, you will accumulate a large number of > these old branch tags. If you then delete a whole series of them, and > run git-gc, the operation will take quite a while, and the number of > blocks and inodes used will grow significantly. They will disappear > after a "git prune", but when I do this housekeeping operation, I've > often wished for a --yes-I-know-what-I-am-doing-and-it's-unsafe-but- > just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repository > option to "git gc".
There was an idea to have "git gc --prune" run "git prune" unconditionally, i.e. without grace period for dangling loose objects.
-- Jakub Narebski Poland ShadeHawk on #git