Subject: Re: [PATCH v4 07/14] bloom: split 'get_bloom_filter()' in two

From: Taylor Blau <[email-masked]>
Date: Sat, 5 Sep 2020 14:38:54 -0400

On Sat, Sep 05, 2020 at 08:18:40PM +0200, Jakub Narębski wrote:
> Hello,
>
> On Sat, 5 Sep 2020 at 20:01, Taylor Blau <[email-masked]> wrote:
> > 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.

That's a very interesting thought. To be honest, I'm not crazy about
generating our own Bloom filters that have special meaning (i.e., that
even though they are interpreted the same way as any other filter, they
are specially-crafted to carry a certain meaning). Your proposal also
means that commit-graph files are going to get bigger, which is
something that you may or may not care about.

On the other hand, it does get rid of the BFXL chunk, which certainly
isn't the most elegant thing.

I don't know. I think my biggest objection is the size: we use the BIDX
chunk today to avoid having to write the length-zero Bloom filters; your
scheme would force us to write every filter. On the other hand, we could
continue to avoid writing length-zero filters, so long as the
commit-graph indicates that it knows this optimization.

Stolee: what do you think?

> Best,
> --
> Jakub Narębski

Thanks,
Taylor