Subject: Is it intended behaviour that 'git gc' ignores the 'commitGraph.changedPaths' setting?

From: Tomasz Konojacki <[email-masked]>
Date: Thu, 04 Jun 2026 13:24:20 +0200

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