Hacker News Reader

Comment by platz | Hacker News Reader

> [1] Note that since Bloom filters are not persisted automatically (that is, you have to pass --changed-paths explicitly on each subsequent write), it is a good idea to disable configuration that automatically generates commit-graphs, like fetch.writeCommitGraph and gc.writeCommitGraph.

Not sure I understand this note

Does this mean that:

    git commit-graph write --reachable --changed-paths

is not a persistent setting, or it is a persistent setting?

View on HN

The data is stored in your `commit-graph` file by this command, but those other ways to update the `commit-graph` file don't pay attention to the fact that the data exists in order to persist it.

There is work in progress to fix that issue, hopefully in the next version: https://lore.kernel.org/git/f1e3a8516ebd58b283166a5374843f5c...

so, then if I want to run

    git log -- /path/to/file

I should always execute

     git commit-graph write --reachable --changed-paths

first, if i've made any changes to the repo (e.g. commits), since the last time i've run it (unless I disable the configuration that automatically generates commit-graphs with fetch.writeCommitGraph and gc.writeCommitGraph) ?

If you don't disable fetch.writeCommitGraph and gc.writeCommitGraph there is a chance that those operations will overwrite your commit-graph and delete the changed-path filter data. (fetch.writeCommitGraph uses the --split option so it might not actually erase the data until you have accumulated enough "new" commits)

You don't need to rewrite the commit-graph file every time you want to run "git log". The "git log" command will parse the newer commits the old-fashioned way until you reach the commits encoded in the commit-graph file. If you do it once now, then you'll still be fast even if a few commits are added on top of your existing history.

If you update the commit-graph with that command once a week, then you'll stay fast even in a very large repository.

> The "git log" commit will parse the newer commits the old-fashioned way until you reach the commits encoded in the commit-graph file. If you do it once now, then you'll still be fast even if a few commits are added on top of your existing history.

Thanks, this is the context I was missing.

Just wanted to avoid a "dirty read" situation.

Thank you for providing the answers here- very helpful!

Reply on news.ycombinator.com