On Wed, 22 Apr 2009, Brandon Casey wrote: > 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'. Why so? Having fewer packs is always a good thing. Having only one pack is of course the optimal situation. The --auto version doesn't do it in the hope of being lightter and less noticeable by the user. However the user manually invoking gc should be expecting some work is actually happening. If you don't want the whole repo read from one pack just to be written in another pack (say the repo is huge and waiting after the IO is not worth it) then just mark such a pack with a .keep file. Nicolas -- 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