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

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

[Tomasz Konojacki]

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

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

[Patrick Steinhardt]

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

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

[Theodore Tso]

On Thu, Jun 04, 2026 at 02:49:44PM +0200, Patrick Steinhardt wrote:
> 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.

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