[stolee]

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...

[platz]

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) ?

[stolee]

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.

[platz]

> 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!