# Re: \[PATCH v2\] worktree list: add --branch to select worktrees by branch

- From: Junio C Hamano \<hidden\>
- Date: 2026-10-28 15:27:05 
- List: git
- Page: https://ratatoskr.run/git/2026/10/17817846
- Thread: https://ratatoskr.run/git/2026/10/17783602/t.md

```text
Eric Sunshine [ref] writes:

> If so, that potentially raises the question about how such filter
> options should combine. It's obvious that multiple
> `--filter=branch:<name>` options combine via logical "OR", but a user
> might want to combine future filter criteria via other logical
> operations (AND, NOT, grouping). Do other Git commands set precedent
> regarding filter option naming and logical operations?
>
> Note that I'm not suggesting that this patch should implement such
> additional filtering behavior (it should not), or even that all these
> questions need to be answered right now. I'm asking only, taking the
> above into consideration, whether this option should be given a more
> generic name to avoid closing the door to those possible future
> enhancements.

Perhaps, but at that point I suspect that the most general form is
to allow you to write a callback function that is given the path to
the worktree and determines if you want the worktree to be included
in the result.  Then

	git worktree list --filter-command='
		test 5 -lt $(git rev-list --count master..HEAD)
	'

may become a way to list worktrees with work that has more than 5
commits to be massaged down to 'master', for example.

"git branch --contains" etc. can be expressed inside the framework,
so "--branch" may become a special case for that more generalized
mechanism.

I dunno.
```