Re: [PATCH 4/4] last-modified: keep per-path Bloom filters for wildcard pathspecs

On Tue, Aug 04, 2026 at 03:19:57PM -0700, Junio C Hamano wrote:

> > It's mostly academic, as both of the pointers (if not NULL) would always
> > point to the same setting that ultimately come from the repository
> > object. But it feels cleaner for them to keep their own pointers,
> > because that pointer may also signal "do we have usable bloom filters".
> > We are a little lucky in dodging a bug here: last-modified uses the
> > pointer for that purpose, but if revision.c did so also, they'd
> > conflict.
> >
> >   Side note: this is really a repository property, so it would be nice
> >   if we could just do:
> >
> >     repo_bloom_filter_contains(filter, &ent->key);
> >
> >   without managing the settings pointer ourselves at all. But the cost
> >   to fetch it from the graph linked list is not totally trivial, so we'd
> >   probably end up having to cache it somewhere. I don't know if that's
> >   worth it (plus last-modified would still have to keep a boolean
> >   somewhere to decide whether it is using bloom filters or not).
> 
> So what happened to this discussion?  Are we happy with the set of
> patches in v1 after all, or are we still thinking it over?

The bit quoted above is mostly quibbling about some refactoring, and I'd
be OK with or without my suggestion. But the "--show-trees" issue that
Taylor raised should be dealt with before moving the topic forward. I
think the next step is probably a re-roll from Toon with a preparatory
patch cleaning up the --show-trees output.

-Peff