On Mon, Jun 11, 2012 at 06:28:43PM -0400, Ted Ts'o wrote: > On Mon, Jun 11, 2012 at 06:23:08PM -0400, Jeff King wrote: > > > > I'm more specifically worried about large objects which are no better in > > packs than they are in loose form (e.g., video files). This strategy is > > a regression, since we are not saving space by putting them in a pack, > > but we are keeping them around much longer. It also makes it harder to > > just run "git prune" to get rid of large objects (since prune will never > > kill off a pack), or to manually delete files from the object database. > > You have to run "git gc --prune=now" instead, so it can make a new pack > > and throw away the old bits (or run "git repack -ad"). > > If we're really worried about this, we could set a threshold and only > pack small objects in the cruft packs. I think I'd be more inclined to just ignore it. It is only prolonging the lifetime of the files by a finite amount (and we are discussing dropping that finite amount anyway). And as a bonus, this strategy could potentially allow an optimization that would make large files better in this case: if we notice that a pack has _only_ unreachable objects, we can simply mark it as ".cruft" without actually repacking it. Coupled with the recent-ish code to stream large blobs directly to packs, that means a large blob which becomes unreachable would not ever be rewritten. > > No! That's exactly what I was worried about with the name. It is _not_ > > safe to do so. It's only safe after you have done a full repack to > > rescue any non-cruft objects. > > Well, yes. I was thinking it would be safe thing to do after a "git > gc" didn't result in enough space savings. This would require that a > git repack always rescue objects from cruft packs even if the -a/-A > options are not specified, but since we're doing a full reachability > scan, that should slow down git gc much, right? Doing "git gc" will always repack everything, IIRC. It is "git gc --auto" which will make small incremental packs. I think we do a full reachability analysis so we can prune there, but that is something I think we should stop doing. It is typically orders of magnitude slower than the incremental repack. -Peff -- 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