Jeff King wrote: > On Tue, Apr 21, 2009 at 05:46:16PM -0400, John Dlugosz wrote: > >> Immediately after doing a git gc, a git fsck --full reports dangling >> objects. Is this normal? What does dangling mean, if not those things >> that gc finds? > > gc will leave dangling loose objects for a set expiration time > (defaulting to two weeks). This makes it safe to run even if there are > operations in progress that want those dangling objects, but haven't yet > added a reference to them (as long as said operation takes less than two > weeks). > > You can also end up with dangling objects in packs. When that pack is > repacked, those objects will be loosened, and then eventually expired > under the rule mentioned above. However, I believe gc will not always > repack old packs; it will make new packs until you have a lot of packs, > and then combine them all (at least that is what "gc --auto" will do; I > don't recall whether just "git gc" follows the same rule). 'git gc' (without --auto) always creates one new pack. I've often wondered whether a plain 'git gc' should adopt the behavior of --auto with respect to the number of packs. If there were few packs, then 'git gc' would do an incremental repack, rather than a 'repack -A -d -l'. I'm still on the fence about it. I think 'git gc' is supposed to be a do-the-right-thing command, so in that sense I think it would be good behavior and it would probably be what most less experienced users want. But, 'git gc' is also used by experienced users who may expect the historical behavior and may _want_ the "pack into one pack" behavior. It could also be that the more experienced users who want the "pack into one pack" behavior are actually the only users of 'git gc', and others just rely on the automatic 'git gc --auto' calling. Not sure. -brandon -- 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