Derrick Stolee [off-list ref] 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.