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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 16, 2024, 22:45 UTC
Message-ID: <xmqqfrywyk16.fsf@gitster.g>
In-Reply-To: <Zabr1Glljjgl/UUB@nand.local>

Taylor Blau <me@ttaylorr.com> writes:

Show 14 quoted lines

> OK, everything seems fine thus far, until we inspect the value of
> g->bloom_filter_settings, which is NULL, becuase of this hunk from
> commit-graph.c::graph_read_bloom_data():
>
>     if (hash_version != 1)
>       return 0;
>
> which terminates the function before we assign g->bloom_filter_settings
> for the existing (written with v2 Bloom filters) graph layer.
>
> I don't think that there is a way to fix this in a backwards compatible
> way, but I'm comfortable with that in this instance since we don't
> expect users to upgrading to v2 Bloom filters and then writing new graph
> layers using a non-v2 compatible version of Git.

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.

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.