# Re: \[PATCH v6 0/7\] Changed path filter hash fix and version bump

- From: Junio C Hamano \<hidden\>
- Date: 2023-07-27 18:44:54 
- List: git
- Page: https://ratatoskr.run/git/2023/07/7972964
- Thread: https://ratatoskr.run/git/2023/07/7972964/t.md

```text
Junio C Hamano [ref] 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.

```