From: Christian Couder Date: Wed, 21 Dec 2022 03:53:50 GMT Subject: Re: [PATCH v3 0/2] Implement filtering repacks Message-ID: In-Reply-To: On Wed, Nov 23, 2022 at 1:31 AM Junio C Hamano wrote: > > Christian Couder writes: > > > In the discussions with Junio and Taylor following the first and > > second versions, Junio suggested adding `--filter=` to > > `git gc` and I am still Ok with doing it, either later in a followup > > patch or in a v4. I haven't done it yet, as it's not clear how to > > implement it efficiently only in `git gc`. > > Did I make such a suggestion? I only said --filter= > does not seem like a good option to surface and stress at the > end-user level for "git pack-objects". In https://lore.kernel.org/git/xmqqilkm9wv6.fsf@gitster.g/ you wrote: -> Unlike prune-packed, pruning objects that could be refetched has -> negative performance impact. So adding an option to enable/disable -> such pruning is needed. If the frontmost UI entry point were "gc", -> it needs an opt-in option to invoke the "filtering repack", in other -> words. "pack-objects" should not need any more work than what you -> have here (with the "terminal" and "force" discarded), as "--filter" -> is such an opt-in option already. I understood the above to mean that you would be Ok with adding a "--filter" flag to `git gc`. > The similarity of "git prune-packed" with this new operation was > brought up to illustrate the point that users of "git gc" do not > want to even know about having to remove redundantly available > objects via "prune-packed" by giving an extra option to "git gc" > (hence --prune is the default), and honoring the filter spec when > objects are known to be available via the configured promisor remote > is likely what users at the "git gc" level would want to see happen > automatically. IOW, adding more options to "gc" would be the last > thing I would want to see. I still think that users should be able to control if `git gc` performs such a filtering when repacking, and I don't see how it could be done without any new option at all. I think that for example only checking the 'remote..partialclonefilter' config variable to decide if it should be done or not is just too dangerous for people already using this variable. In the v4 I will send really soon now, I tentatively implemented a 'gc.repackFilter' config option for the purpose of telling `git gc` that it should perform filtering repacks with the specified filter. I hope that this will help move the discussion forward. BTW in the latest "What's cooking in git.git" emails there is the following about this patch series: -> Seems to break CI. -> cf. https://github.com/git/git/actions/runs/3560918726 I took a look at the failures in the different failing tests and they don't seem related to this patch series and seem quite random: === Failed test: t3106-ls-tree-pattern === The full logs are in the 'print test failures' step below. See also the 'failed-tests-*' artifacts attached to this run. Error: failed: t3106.3 combine with "--object-only" failure: t3106.3 combine with "--object-only" Error: failed: t3106.5 combine with "--long" failure: t3106.5 combine with "--long" === Failed test: t5601-clone === The full logs are in the 'print test failures' step below. See also the 'failed-tests-*' artifacts attached to this run. skip: t5601.60 clone c:temp is dos drive skip: t5601.101 colliding file detection Error: failed: t5601.110 auto-discover bundle URI from HTTP clone failure: t5601.110 auto-discover bundle URI from HTTP clone Error: failed: t5601.111 auto-discover multiple bundles from HTTP clone failure: t5601.111 auto-discover multiple bundles from HTTP clone === Failed test: t5556-http-auth === The full logs are in the 'print test failures' step below. See also the 'failed-tests-*' artifacts attached to this run. Error: failed: t5556.2 http auth anonymous no challenge failure: t5556.2 http auth anonymous no challenge Error: failed: t5556.3 http auth www-auth headers to credential helper bearer valid failure: t5556.3 http auth www-auth headers to credential helper bearer valid === Failed test: t4203-mailmap === The full logs are in the 'print test failures' step below. See also the 'failed-tests-*' artifacts attached to this run. Error: failed: t4203.66 git cat-file -s returns correct size with --use-mailmap failure: t4203.66 git cat-file -s returns correct size with --use-mailmap Error: failed: t4203.67 git cat-file -s returns correct size with --use-mailmap for tag objects failure: t4203.67 git cat-file -s returns correct size with --use-mailmap for tag objects etc I tried different build flags but can't reproduce locally.