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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 28, 2026, 15:27 UTC
Message-ID: <xmqqik2ldewp.fsf@gitster.g>
In-Reply-To: <CAPig+cT6rxKptqSEKuVbi2FafBqh+DfcHAkHfz2-=SH3y2hfyw@mail.gmail.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

Show 13 quoted lines

> 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.