Re: [PATCH v4 1/4] gitformat-commit-graph: describe version 2 of BDAT

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