Re: What's cooking in git.git (Jan 2024, #01; Tue, 2)

Taylor Blau [off-list ref] writes:

quoted

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.

quoted

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.