Git development
 help / color / mirror / Atom feed
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

  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