Re: [PATCH v6 0/7] Changed path filter hash fix and version bump
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 27, 2023, 18:44 UTC
- Message-ID
- <xmqqpm4db3dv.fsf@gitster.g>
- In-Reply-To
- <xmqqzg3ib2ma.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> ... How hard it would be to construct a test > case that fails if filter computed as v1 is marketed as v2?
There may be a more effective way for future-proofing, besides ensuring the test coverage.
Although this series added a way to see which version the on-disk data is using using the version field, I do not think it touched the "struct bloom_filter" and "struct bloom_key" that represent the in-core data. If we had a member in these structures that get_or_compute_bloom_filter() can fill in from the on-disk structure or the version it used when it computed the filter anew, would it become easier to catch the case where we try to add a version 2 computed key to a filter that was read from version 1 on-disk structure, presumably at add_key_to_filter()?
Thanks.