5 ms·

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

• platz 6y ago
  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 6y ago
    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 6y ago
      > 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!