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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox