On Wed, Nov 23, 2022 at 1:31 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Christian Couder <christian.couder@xxxxxxxxx> writes: > > > In the discussions with Junio and Taylor following the first and > > second versions, Junio suggested adding `--filter=<filter-spec>` 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=<filter-spec> > 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.<name>.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.
