On Wed, Mar 18, 2015 at 09:27:22PM -0400, Jeff King wrote: > On Thu, Mar 19, 2015 at 07:31:48AM +0700, Duy Nguyen wrote: > > > Or we could count/estimate the number of loose objects again after > > repack/prune. Then we can maybe have a way to prevent the next gc that > > we know will not improve the situation anyway. One option is pack > > unreachable objects in the second pack. This would stop the next gc, > > but that would screw prune up because st_mtime info is gone.. Maybe we > > just save a file to tell gc to ignore the number of loose objects > > until after a specific date. > > I don't think packing the unreachables is a good plan. They just end up > accumulating then, and they never expire, because we keep refreshing > their mtime at each pack (unless you pack them once and then leave them > to expire, but then you end up with a large number of packs).
Note, sometimes I wish unreachables were packed. Recently, I ended up in a situation where running gc created something like 3GB of data as per du, because I suddenly had something like 600K unreachable objects, each of them, as a loose object, taking at least 4K on disk. This made my .git take 5GB instead of 2GB. That surely didn't feel like garbage collection. Mike -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
