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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 16, 2024, 23:42 UTC
Message-ID: <xmqqedegx2tt.fsf@gitster.g>
In-Reply-To: <ZacRx1rbESvYiVgN@nand.local>

Taylor Blau <me@ttaylorr.com> writes:

Show 10 quoted lines

>> 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.

Show 9 quoted lines

>> 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.