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

From: Taylor Blau <me@ttaylorr.com>
Date: Sep 5, 2020, 19:49 UTC
Message-ID: <20200905194926.GA7964@nand.local>
In-Reply-To: <20200905190449.GB6209@szeder.dev>

On Sat, Sep 05, 2020 at 09:04:50PM +0200, SZEDER Gábor wrote:

Show 21 quoted lines

> On Sat, Sep 05, 2020 at 02:55:34PM -0400, Taylor Blau wrote:
> > On Sat, Sep 05, 2020 at 02:38:54PM -0400, Taylor Blau wrote:
> > > 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.
> >
> > Thinking about it a little bit more, I'm pretty sure that this isn't as
> > easy as it sounds. Say that we:
> >
> >   - continued to encode length-zero Bloom filters as equal adjacent
> >     entries in the BIDX, but reserve the length-zero filter for commits
> >     with no changed-paths, _or_ commits whose Bloom filters have not yet
> >     been computed
>
> No, use zero-length filters for commits whose Bloom filters have not
> yet been computed, and use a one-byte all zero bits Bloom filter for
> commits with no modified paths.
>
> And this is exactly what I proposed earlier.

Fair enough, I bet that would work.

Junio, let's eject this series while I try to see if SZEDER's idea is workable.

> > I don't see a non-convoluted way to split the overloaded length-zero
> > case into something that is distinguishable without a format extension.
>
> See above, no format extension needed.

Where?

Thanks, Taylor