On Fri, Jan 29, 2021 at 03:25:37PM -0500, Jeff King wrote: > So it may be reasonable to go that direction, which is really defining a > totally separate strategy from git-gc's "repack, and occasionally > objects age out". Especially if we find that the > assume-kept-packs-closed route is too risky (i.e., has too many cases > where it's possible to cause corruption if our assumptions isn't met). Yeah, this whole conversation has made me very nervous about using reachability. Fundamentally, this isn't about reachability at all. The operation is as simple as telling pack-objects a list of packs that you do and don't want objects from, making a new pack out of that, and then optionally dropping the packs that you rolled up. So, I think that teaching pack-objects a way to understand a caller that says "include objects from packs X, Y, and Z, but not if they appear in packs A, B, or C, and also pull in any loose objects" is the best way forward here. Of course, you're going to be dragging along unreachable objects until you decide to do a full repack, but I'm OK with that since we wouldn't expect anybody to be solely relying on geometric repacks without occasionally running 'git repack -ad'. Junio: I don't think that you have picked this up yet, but please avoid doing so for now, and I'll send a new series that goes in the direction I outlined above. Thanks, Taylor
