From: Toon Claes <toon@iotcl.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Gusted <gusted@codeberg.org>
Subject: Re: [PATCH 1/4] revision: move bloom keyvec precondition into function
Date: Wed, 05 Aug 2026 21:16:00 +0200 [thread overview]
Message-ID: <87wlu44bv3.fsf@emacs.iotcl.com> (raw)
In-Reply-To: <20260718075700.GB22588@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Jul 17, 2026 at 05:46:59PM +0200, Toon Claes wrote:
>
>> There are currently two callsites calling
>> check_maybe_different_in_bloom_filter(). They both check if
>> revs->bloom_keyvecs_nr is not zero before they call that function.
>>
>> Move bloom_keyvecs_nr precondition into
>> check_maybe_different_in_bloom_filter() to simplify the code.
>
> Makes sense, but...
>
>> Note that this changes `bloom_ret` to become -1 when there are no Bloom
>> key vectors, which results in `count_bloom_filter_false_positive` not
>> being incremented. This is unobservable, as the Bloom statistics are
>> only reported when key vectors were set up.
>
> This "-1" return is kind of subtle. The function is really a tristate
> returning one of:
>
> 0: no, it's definitely not in the filter
> 1: yes, it's (probably) in the filter
> -1: we could not even check the filter
>
> But nobody ever cares about the difference between "1" and "-1", because
> the probabilistic data structure means "we could not check" must err on
> the side of "it might be in the filter".
That's not entirely true. The `count_bloom_filter_false_positive`
depends on knowing whether the filter said "maybe" or if no filter was
used at all.
> But that leads to code like:
>
> if (!bloom_ret)
>
> that _looks_ wrong at first glance (as in "oops, we are not catching -1
> and accidentally treating it the same as 1"). But it's is actually
> correct for the reason above.
>
> The "return -1" you are adding here is not the first (we'd do a similar
> thing if the commit was not found in the graph file). So it is not
> really adding to the confusion.
>
> But as we prepare to make this function public, should we consider
> changing that tristate to a boolean, like:
>
> false: no, the path is definitely not touched by this commit
> true: the path could be touched by this commit
>
> It's a minor point, but I think this makes the interface much more
> obvious.
That said, the public function might have a boolean interface, while
the private wrapper still uses the tristate. I'll address in the next
version.
--
Cheers,
Toon
next prev parent reply other threads:[~2026-08-05 19:16 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 15:46 [PATCH 0/4] last-modified: use the pathspec's Bloom key to pre-filter commits Toon Claes
2026-07-17 15:46 ` [PATCH 1/4] revision: move bloom keyvec precondition into function Toon Claes
2026-07-18 7:57 ` Jeff King
2026-08-05 19:16 ` Toon Claes [this message]
2026-08-05 20:32 ` Jeff King
2026-07-17 15:47 ` [PATCH 2/4] revision: expose check for paths maybe changed in Bloom filter Toon Claes
2026-07-17 20:47 ` Junio C Hamano
2026-07-17 23:26 ` Taylor Blau
2026-07-17 15:47 ` [PATCH 3/4] last-modified: check pathspec against Bloom filter first Toon Claes
2026-07-17 23:05 ` Taylor Blau
2026-07-18 8:37 ` Jeff King
2026-07-18 21:22 ` Taylor Blau
2026-07-20 9:42 ` Jeff King
2026-07-17 15:47 ` [PATCH 4/4] last-modified: keep per-path Bloom filters for wildcard pathspecs Toon Claes
2026-07-17 19:16 ` Toon Claes
2026-07-18 8:14 ` Jeff King
2026-08-04 22:19 ` Junio C Hamano
2026-08-05 0:43 ` Taylor Blau
2026-08-05 16:01 ` Junio C Hamano
2026-08-05 1:18 ` Jeff King
2026-07-17 23:18 ` Taylor Blau
2026-07-17 19:13 ` [PATCH 0/4] last-modified: use the pathspec's Bloom key to pre-filter commits Toon Claes
2026-08-07 18:26 ` [PATCH v2 0/6] " Toon Claes
2026-08-07 18:26 ` [PATCH v2 1/6] revision: move bloom keyvec precondition into function Toon Claes
2026-08-07 18:26 ` [PATCH v2 2/6] revision: expose check for paths maybe changed in Bloom filter Toon Claes
2026-08-07 18:26 ` [PATCH v2 3/6] bloom: add helper to check if any key in a vector is present Toon Claes
2026-08-07 18:26 ` [PATCH v2 4/6] revision: add Bloom check that includes parent directories Toon Claes
2026-08-07 18:26 ` [PATCH v2 5/6] last-modified: check pathspec against Bloom filter first Toon Claes
2026-08-07 18:26 ` [PATCH v2 6/6] last-modified: keep per-path Bloom filters for wildcard pathspecs Toon Claes
2026-08-08 17:07 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wlu44bv3.fsf@emacs.iotcl.com \
--to=toon@iotcl.com \
--cc=git@vger.kernel.org \
--cc=gusted@codeberg.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.