Dangling blob after git gc

Hi,

$ git version git version 1.6.0.4

$ git fsck dangling blob 070011dddba40fe0066cbebfe51ea6d160f95af8 dangling blob 3ec00c535bbac37f738971a5ad14bb11892c5863 dangling commit c180face4d2451f9e77f41d4f9d4f3ad7cbd51c0 (...)

So I have multiple dangling blobs/trees/commits, let's do a gc.

$ git gc Counting objects: 96978, done. Compressing objects: 100% (25044/25044), done. Writing objects: 100% (96978/96978), done. Total 96978 (delta 70392), reused 96978 (delta 70392)

$ git fsck dangling commit 2302e3fd37e808d3240ffa887ea1c22cac9cb770 dangling commit 0a2bc7013d49e0695242ffc2d57360d0396c22ea dangling blob c330f89bcc20b1c9ca689e66062d086562e0633d dangling commit ac319ab8d187e818f2dd05774175a2a7feb9696e dangling commit a5f5b7956f7d63bab13d3f2c45c7315cfbea28b8

The commits are probably due to reflogs, that's OK. But why do I have a dangling blob after git gc? The interesting part is that as you can see most of them is removed, but not all.

Any ideas? :)

Thanks.

Miklos Vajna <vmiklos@frugalware.org> writes:

from man git-gc:

     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".

Git can hardly know for sure whether a dangling object is actually a temporary object used by another instance of git or actually an unused object. Older versions of Git required you to explicitely say --prune to mean "OK, _I_ am sure, you can prune the objects", newer do it the safe way by removing only objects old enough.

On Thu, Nov 27, 2008 at 02:46:47PM +0100, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:

So it was a user error, thanks for pointing out the relevant documentation. :)