On Mon, Oct 09, 2023 at 02:17:54PM -0400, Taylor Blau wrote: > On Sun, Oct 08, 2023 at 04:35:23PM +0200, SZEDER Gábor wrote: > > > Hmm. I am confused -- are you saying that this series breaks existing > > > functionality, or merely does not patch an existing breakage? I *think* > > > that it's the latter, > > > > It's neither: the new functionality added in this series is broken. > > > > > since this test case fails identically on master, > > > but I am not sure. > > > > Not sure what test you are referring to. My test demonstrating the > > breakage succeeds when adaped to master, because master doesn't > > understand the commitgraph.changedPathsVersion=2 setting, and keeps > > writing v1 Bloom filter chunks instead, so all commit-graphs layers > > contain the same version. > > I was referring to the test you sent back in: > > https://public-inbox.org/git/20201015132147.GB24954@xxxxxxxxxx/ > > but I think that I should have been looking at the one you sent more > recently in: > > https://lore.kernel.org/git/20230830200218.GA5147@xxxxxxxxxx/ OK, I think that I now have my head wrapped around what you're saying. 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. How does that sound? Thanks, Taylor
