Hi Derrick, On Wed, 2 Feb 2022 at 15:02, Robert Coup <robert@xxxxxxxxxxx> wrote: > On Tue, 1 Feb 2022 at 20:13, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > "Robert Coup via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > 1. This will produce duplicated objects between the existing and newly > > > fetched packs, but gc will clean them up. > > > > Hopefully, at the end of this > > operation, we should garbage collect the duplicated objects by > > default (with an option to turn it off)? > > I haven't explicitly looked into invoking gc yet, but yes, it'd be a bit of > a waste if it wasn't kicked off by default. Maybe reusing gc.auto Just looking into this: after a fetch, run_auto_maintenance() is called, which invokes `git maintenance run --auto` (being the successor to `git gc --auto`)... In the refilter (repair) case, we'll have a new pack which substantially duplicates what's in our existing packs. I'm after some advice here: I'm not sure whether I want to encourage a gc pack consolidation, an incremental repack, both, neither, or something else? My current train of thought is it invokes `git maintenance run --auto` with gc.autoPackLimit=1 to force a gc pack consolidation if it's not currently =0 (disabled), and with maintenance.incremental-repack.auto=-1 if it's not currently =0 (disabled) to force an incremental repack if someone doesn't want to do pack consolidations. In all cases the various enabled-ness settings should still be honoured to skip tasks if the user doesn't want them ever happening automatically. Implementation-wise I guess we'll need run_auto_maintenance() to be able to pass some config options through to the maintenance subprocess. Does this sound like a reasonable approach? Thanks, Rob :)
