Taylor Blau <me@xxxxxxxxxxxx> writes: > > I wonder if we want to mention what the undesired misbehaviour the > > "bug" causes and what we do to avoid getting affected by the bug > > here. If we can say something like "When querying for a pathname > > with a byte with high-bit set, the buggy filter may produce false > > negative, making the filter unusable, but asking for a pathname > > without such a byte produces no false negatives (even though we may > > get false positives). When Git reads version 1 filter data, it > > refrains from using it for processing paths with high-bit set to > > avoid triggering the bug", then it would be ideal. > > Your description of the bug matches my understanding of the issue, that > a corrupt filter would produce false negatives and thus be unusable. > > I skimmed through the rest of the series, and couldn't find a spot where > we do the latter, i.e. still use v1 filters as long as we don't have any > characters in the path with high-order bits set. > > I think this would be as simple as modifying the Bloom filter query > function to return "maybe" before even trying to hash a path with at > least one character with its high-bit set. > > Apologies if this functionality is implemented and I just missed it. > > Thanks, > Taylor Thanks for the suggestion - yeah, this might work.
