Taylor Blau <me@xxxxxxxxxxxx> writes: >> A big red button solution to avoid this would be to uprev the >> repository format version once you start writing v2 Bloom filters >> anywhere in the layers. That way, existing Git clients would not be >> able to touch it. I do not know if the cure is more severe than the >> disease in that case, though. > > I tend to think that in this case the cure is probably worse than the > disease. I expect it to be extremely rare that a user would upgrade to a > modern version of Git, write commit-graphs, then downgrade, and try to > write more commit-graphs. But then the big red button solution would rarely misfire for users because they will not downgrade (and see "gee, I now need to stick to the newer version"), no? I am not seriously suggesting to do this, but I am not sure if documenting "don't do this because you'll break your repository" is sufficient. >> In any case, at least, we should be able to prepare the code that we >> teach to grok v2 today so that they do not trigger the same segfault >> when they see a commit graph layer containing v3 Bloom filters (or >> later). Then we won't have to have the same conversation when we >> somehow need to update Bloom filters again. > > This series should accomplish that by loading the Bloom chunk > unconditionally, and only reading its filters when they match the > given hash_version. Good.
