{"thread":{"id":"65751","subject":"Is it intended behaviour that 'git gc' ignores the 'commitGraph.changedPaths' setting?","startedAt":"2026-06-04T11:24:22Z","lastAt":"2026-06-04T14:28:14Z","messageCount":3,"participants":["Tomasz Konojacki","Patrick Steinhardt","Theodore Tso"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"544724","messageId":"20260604132419.F2FA.5C4F47F8@xenu.pl","threadId":"65751","inReplyTo":null,"subject":"Is it intended behaviour that 'git gc' ignores the 'commitGraph.changedPaths' setting?","fromName":"Tomasz Konojacki","fromEmail":"me@xenu.pl","sentAt":"2026-06-04T11:24:20Z","receivedAt":"2026-06-04T11:24:22Z","isPatch":false,"body":"Hi,\n\nIt seems that 'git gc' (and also 'fetch' with 'fetch.writeCommitGraph'\nenabled) ignore the 'commitGraph.changedPaths' setting.\n\nSee the output below, the commands are being executed on a repo that\ndoesn't have a commit-graph generated:\n\n$ git --version\ngit version 2.54.0\n\n$ git config --global --get-all commitGraph.changedPaths\ntrue\n\n$ git gc\nEnumerating objects: 674076, done.\nCounting objects: 100% (674076/674076), done.\nDelta compression using up to 16 threads\nCompressing objects: 100% (137084/137084), done.\nWriting objects: 100% (674076/674076), done.\nTotal 674076 (delta 524292), reused 673941 (delta 524158), pack-reused 0 (from 0)\nEnumerating cruft objects: 6160, done.\nTraversing cruft objects: 12279, done.\nCounting objects: 100% (6160/6160), done.\nDelta compression using up to 16 threads\nCompressing objects: 100% (1802/1802), done.\nWriting objects: 100% (6160/6160), done.\nTotal 6160 (delta 4314), reused 6160 (delta 4314), pack-reused 0 (from 0)\nExpanding reachable commits in commit graph: 131458, done.\n\n$ git commit-graph write\nExpanding reachable commits in commit graph: 132865, done.\nComputing commit changed paths Bloom filters: 100% (132865/132865), done.\n\nAs you can see, 'gc' didn't create changed paths bloom filters, only a\ndirect call to 'commit-graph write' did.\n\nIs this intended behaviour? It's very surprising to me.\n\nAlso, is there a way to make 'gc' and 'fetch' generate changed path\nbloom filters?\n\nThanks,\nTomasz\n\n\n"},{"id":"544743","messageId":"aiF0aN9BwBvQffGL@pks.im","threadId":"65751","inReplyTo":"20260604132419.F2FA.5C4F47F8@xenu.pl","subject":"Re: Is it intended behaviour that 'git gc' ignores the 'commitGraph.changedPaths' setting?","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-06-04T12:49:44Z","receivedAt":"2026-06-04T12:49:52Z","isPatch":false,"body":"Hi,\n\nOn Thu, Jun 04, 2026 at 01:24:20PM +0200, Tomasz Konojacki wrote:\n> It seems that 'git gc' (and also 'fetch' with 'fetch.writeCommitGraph'\n> enabled) ignore the 'commitGraph.changedPaths' setting.\n\nI think this is a bug -- it really should write the bloom filters when\nyou've enabled the above config option.\n\nThe root cause of this seems to be that we call\n`write_commit_graph_reachable()` directly, and that basically means that\nit becomes git-gc(1)'s responsibility to set all the correct flags. And\nas we don't pay attention to \"commitGraph.changedPaths\" at all we simply\nignore it.\n\nIn Git 2.54, the default housekeeping strategy used by git-maintenance(1)\nhas changed from using git-gc(1) to use individual tasks for more\nflexibility. One of these tasks is responsible for writing commit\ngraphs, and that task doesn't call `write_commit_graph_reachable()` but\ninstead executes git-commit-graph(1) directly. And because we do this\ninfrastructure works correctly.\n\nSo my recommendation would be to stop using git-gc(1) altogether -- I am\nbiased as I have helped implementing the new maintenance strategy, but I\nwould say that git-gc(1) is nowadays a legacy tool that inches closer\ntowards the end of its life. Git's default maintenance nowadays uses\ngit-maintenance(1) without using git-gc(1) at all anymore.\n\nWe could of course fix this, and it shouldn't be all that hard to do.\nWe'd either start using `run_write_commit_graph()` directly in git-gc(1)\nor we'd start respecting the config option to pass the additional flag.\nI myself probably don't care enough about git-gc(1) to do that anymore,\nbut if anybody else feels like it I'm happy to review.\n\nThanks!\n\nPatrick\n"},{"id":"544746","messageId":"zzxyeseps5rflyldmdlx54dkjlyu4v267wbpfb4xlrh4lahogf@3woimupgfm7v","threadId":"65751","inReplyTo":"aiF0aN9BwBvQffGL@pks.im","subject":"Re: Is it intended behaviour that 'git gc' ignores the 'commitGraph.changedPaths' setting?","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2026-06-04T14:27:05Z","receivedAt":"2026-06-04T14:28:14Z","isPatch":false,"body":"On Thu, Jun 04, 2026 at 02:49:44PM +0200, Patrick Steinhardt wrote:\n> So my recommendation would be to stop using git-gc(1) altogether -- I am\n> biased as I have helped implementing the new maintenance strategy, but I\n> would say that git-gc(1) is nowadays a legacy tool that inches closer\n> towards the end of its life. Git's default maintenance nowadays uses\n> git-maintenance(1) without using git-gc(1) at all anymore.\n\nI wonder if we should add a tunable that makes \"git gc\" redirect to\n\"git maintenance run\" or some such.  For those of us who like to\nlaunch maintenance tasks at specific times (for example, before I\ndisconnect from the AC mains and get on a plane), \"git gc\" has a major\nadvantage --- it has fewer characters to type, and I'm lazy.  :-)\n\nThe other things to perhaps suggest is ways that developers can set up\nrules like disabling git maintenace running while on battery, etc.\nThis might require OS-specific mechanisms for determining whether the\nlaptop is running on battery --- but I note that git-maintenance is\nalready hooked into systemd and launchctl for Linux and MacOS,\nrespectively, so there's precedent for that sort of thing.\n\nCheers,\n\n\t\t\t\t\t- Ted\n"}]}