Re: [RFC PATCH 3/7] path-walk: support `object:type` filter

[Derrick Stolee <stolee@gmail.com>]

On 5/3/2026 8:11 PM, Taylor Blau wrote:
> The `object:type` filter accepts only objects of a single type; it is
> the second member of the object-info-only filter family that bitmap
> traversal already supports.

...

> But there are a couple of side effects of the "trees off, blobs on" case
> that need fixing:
> 
>  1. 'setup_pending_objects()' previously skipped pending trees as soon
>     as `info->trees` was zero. For 'object:type=blob' the call site
>     needs those pending trees: a lightweight tag pointing to a tree, or
>     an annotated tag whose peeled target is a tree, can both reach
>     blobs that are otherwise unreachable from any commit's root tree.
>     Loosen the gate to "if (!info->trees && !info->blobs) continue" and
>     similarly retrieve the root_tree_list whenever either trees or
>     blobs are wanted.
> 
>  2. The revision machinery's `handle_commit()` drops pending trees when
>     `revs->tree_objects` is zero (see the 'OBJ_TREE' handler in
>     revision.c), so by the time path-walk sees the pending list
>     after `prepare_revision_walk()` the tree-bearing pendings would
>     already be gone. Fix this by setting
> 
>         revs->tree_objects = info->trees || info->blobs
> 
>     so pending trees survive `prepare_revision_walk()` whenever we
>     need to walk into them. Path-walk still resets tree_objects to
>     zero immediately after `prepare_revision_walk()` returns, so the
>     rev-walk itself never enumerates trees redundantly with
>     path-walk's own descent.

Both of these changes are very valuable bug fixes for the path-walk API!
Thanks for catching the distinction here where we should still be
walking trees in order to find the blobs we want.

Thanks,
-Stolee