On Sat, Jan 20 2018, Junio C. Hamano jotted: > Theodore Ts'o <tytso@xxxxxxx> writes: > >> .... I've never been fond of the "git repack -A" behavior >> where it can generate huge numbers of loose files. I'd much prefer it >> if the other objects ended up in a separate pack file, and then some >> other provision made for nuking that pack file some time later.... > > 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.
