On Mon, Oct 09, 2023 at 12:52:13PM -0700, Junio C Hamano wrote: > 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? Very good suggestion, thanks. Thanks, Taylor
