Hello, On Sat, 5 Sep 2020 at 20:01, Taylor Blau <me@xxxxxxxxxxxx> wrote: > On Sat, Sep 05, 2020 at 07:50:01PM +0200, Jakub Narębski wrote: > > On Sat, 5 Sep 2020 at 19:38, Taylor Blau <me@xxxxxxxxxxxx> wrote: > > > > > > Right, once we get handed back a filter from > > > 'get_or_compute_bloom_filter()', we can't distinguish between (a) a > > > commit with too many changes to store in a single Bloom filter, and (b) > > > a commit with no changes at all. > > > > We could change how we store either no-changes Bloom filter (as all > > zeros minimal size filter), or too-many-changes Bloom filter (as all > > ones, i.e. max unsigned value, minimal size filter). This change would > > not require to change any user of Bloom filter. > > I don't think that's true. Say that we changed the empty Bloom filter to > be encoded as only having the most-significant bit set. First, we'd have > to write a Bloom filter where we didn't have to before. That's true. > But the real > issue is that commit-graph files generated with new clients would > suddenly be unreadable by old clients. Actually it is, at least in the form that I have proposed. The Bloom filter which has all bits set to zero would for every possible path reply that the path is not in set. Old clients would therefore work without changes. Therefore this is good representation of no-changes Bloom filter. The Bloom filter which has all bits set to one would for every possible path reply that the path is maybe in set. This is a good alternative representation of too-many-changes Bloom filter. Again, old clients would work without changes. [...] Best, -- Jakub Narębski
