Hi,

It seems that 'git gc' (and also 'fetch' with 'fetch.writeCommitGraph' enabled) ignore the 'commitGraph.changedPaths' setting.

See the output below, the commands are being executed on a repo that doesn't have a commit-graph generated:

$ git --version git version 2.54.0

$ git config --global --get-all commitGraph.changedPaths true

$ git gc Enumerating objects: 674076, done. Counting objects: 100% (674076/674076), done. Delta compression using up to 16 threads Compressing objects: 100% (137084/137084), done. Writing objects: 100% (674076/674076), done. Total 674076 (delta 524292), reused 673941 (delta 524158), pack-reused 0 (from 0) Enumerating cruft objects: 6160, done. Traversing cruft objects: 12279, done. Counting objects: 100% (6160/6160), done. Delta compression using up to 16 threads Compressing objects: 100% (1802/1802), done. Writing objects: 100% (6160/6160), done. Total 6160 (delta 4314), reused 6160 (delta 4314), pack-reused 0 (from 0) Expanding reachable commits in commit graph: 131458, done.

$ git commit-graph write Expanding reachable commits in commit graph: 132865, done. Computing commit changed paths Bloom filters: 100% (132865/132865), done.

As you can see, 'gc' didn't create changed paths bloom filters, only a direct call to 'commit-graph write' did.

Is this intended behaviour? It's very surprising to me.

Also, is there a way to make 'gc' and 'fetch' generate changed path bloom filters?

Thanks, Tomasz

Hi,

On Thu, Jun 04, 2026 at 01:24:20PM +0200, Tomasz Konojacki wrote:

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

On Thu, Jun 04, 2026 at 02:49:44PM +0200, Patrick Steinhardt wrote:

I wonder if we should add a tunable that makes "git gc" redirect to "git maintenance run" or some such. For those of us who like to launch maintenance tasks at specific times (for example, before I disconnect from the AC mains and get on a plane), "git gc" has a major advantage --- it has fewer characters to type, and I'm lazy. :-)

The other things to perhaps suggest is ways that developers can set up rules like disabling git maintenace running while on battery, etc. This might require OS-specific mechanisms for determining whether the laptop is running on battery --- but I note that git-maintenance is already hooked into systemd and launchctl for Linux and MacOS, respectively, so there's precedent for that sort of thing.

Cheers,

					- Ted