On Tue, Jun 20, 2023 at 09:43:46AM -0400, Derrick Stolee wrote: > This version is not ready. The backwards compatibility story is > incomplete. I'm also late to the party, but I agree with Stolee here, having come to the same conclusion about needing to support reading older (corrupt) Bloom filters when possible (i.e. when paths contain no bytes which have their high-order bits set), and assuming the filter contains all paths otherwise. > 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. I am not sure if there's a situation where we'd ever want to not write the newer versions when starting a new commit-graph (or chain) from scratch. I think that follows from what you and I are both suggesting w.r.t backwards compatibility. If that's the case, I think that we could in theory drop this configuration setting altogether. Or, at the very least, we should be able to change it change only what version we *write*, not read. I think this is what you are suggesting above, but I am not 100% sure, so apologies if I'm just repeating what you've already suggested. > 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. Yup, good suggestion. Thanks, Taylor
