From: Patrick Steinhardt Date: Thu, 04 Jun 2026 12:49:44 GMT Subject: Re: Is it intended behaviour that 'git gc' ignores the 'commitGraph.changedPaths' setting? Message-ID: In-Reply-To: <20260604132419.F2FA.5C4F47F8@xenu.pl> Hi, On Thu, Jun 04, 2026 at 01:24:20PM +0200, Tomasz Konojacki wrote: > It seems that 'git gc' (and also 'fetch' with 'fetch.writeCommitGraph' > enabled) ignore the 'commitGraph.changedPaths' setting. I think this is a bug -- it really should write the bloom filters when you've enabled the above config option. The root cause of this seems to be that we call `write_commit_graph_reachable()` directly, and that basically means that it becomes git-gc(1)'s responsibility to set all the correct flags. And as we don't pay attention to "commitGraph.changedPaths" at all we simply ignore it. In Git 2.54, the default housekeeping strategy used by git-maintenance(1) has changed from using git-gc(1) to use individual tasks for more flexibility. One of these tasks is responsible for writing commit graphs, and that task doesn't call `write_commit_graph_reachable()` but instead executes git-commit-graph(1) directly. And because we do this infrastructure works correctly. So my recommendation would be to stop using git-gc(1) altogether -- I am biased as I have helped implementing the new maintenance strategy, but I would say that git-gc(1) is nowadays a legacy tool that inches closer towards the end of its life. Git's default maintenance nowadays uses git-maintenance(1) without using git-gc(1) at all anymore. We could of course fix this, and it shouldn't be all that hard to do. We'd either start using `run_write_commit_graph()` directly in git-gc(1) or we'd start respecting the config option to pass the additional flag. I myself probably don't care enough about git-gc(1) to do that anymore, but if anybody else feels like it I'm happy to review. Thanks! Patrick