Taylor Blau <me@xxxxxxxxxxxx> writes: > However, I am not entirely sure I agree with you that this is a "new" > issue. At least in the sense that Git (on 'master') does not currently > know how to deal with Bloom filters that have different settings across > commit-graph layers. > > IOW, you could produce this problem today using the test you wrote in > <20201015132147.GB24954@xxxxxxxxxx> using different values of the > GIT_BLOOM_SETTINGS environment variables as a proxy for different values > of the commitGraph.changedPathsVersion configuration variable introduced > in this series. > > So I think that this series makes it easier to fall into that trap, but > the trap itself is not new. I think a reasonable stopgap (which IIUC you > have suggested earlier) is to prevent writing a new commit-graph layer > with a different hash version than the previous layer. What we probably want more urgently than that stopgap is to perhaps teach the code pretend as if commit-graph did not exist when we detect multiple layers use different hash versions (or perhaps only use the base layer and ignore the rest as an anti-pessimization), to protect correctness first, no?
