Derrick Stolee <derrickstolee@xxxxxxxxxx> writes: > When commitGraph.changedPathsVersion is set, it does not allow > reading a previous filter version, leaving us in a poor performance > state until the commit-graph file can be rewritten. > > While I was reviewing, it seemed reasonable to deprecate > commitGraph.readChangedPaths, but this use of "also restrict writes > to this version" didn't make sense to me at the time. Instead, it > would be good to have this clarity between the config options: > > commitGraph.readChangedPaths: should we read and use the filters > that exist on disk? Defaults to 'true'. > > commitGraph.changedPathsVersion: Which version should we _write_ > when writing a new commit-graph? Defaults to '1' but will default > to '2' in the next major verion, then '1' will no longer be an > accepted value in the version after that. > > The tricky part is that during the commit-graph write, you will > need to check the existing filter value to see if it matches. If > not, the filters will need to be recomputed from scratch. This > will change patch 4 a bit, but it's the right thing to do. > > Thanks, > -Stolee OK - this sounds reasonable. I'll take a look.
