On Mon, Jan 22, 2018 at 04:09:23PM +0100, Ævar Arnfjörð Bjarmason wrote: > > Yes, a "cruft pack" that holds unreachable object has been discussed > > a few times recently on list, and I do agree that it is a desirable > > thing to have in the longer run. > > > > What's tricky is to devise a way to allow us to salvage objects that > > are placed in a cruft pack because they are accessed recently, > > proving themselves to be no longer crufts. It could be that a good > > way to resurrect them is to explode them to loose form when they are > > accessed out of a cruft pack. We need to worry about interactions > > with read-only users if we go that route, but with the current > > "explode unreachable to loose, touch their mtime when they are > > accessed" scheme ends up ignoring accesses from read-only users that > > cannot update mtime, so it might not be too bad. > > Wouldn't it also make gc pruning more expensive? Now you can repack > regularly and loose objects will be left out of the pack, and then just > rm'd, whereas now it would entail creating new packs (unless the whole > pack was objects meant for removal). > > Probably still worth it, but something to keep in mind. That's a good point. I think it would be OK in practice, though, since normal operations don't tend to create a huge number of unreachable loose objects (at least compared to the _reachable_ loose objects, which we're already dealing with). We tend to get unbalanced explosions of loose objects only because a huge chunk of packed history expired. It is something to keep in mind when implementing the scheme, though. Luckily we already have the right behavior implemented via --pack-loose-unreachable (which is used for "repack -k" currently), so I think it would just be a matter of passing the right flags from git-repack. -Peff
