From: Junio C Hamano Date: Wed, 28 Oct 2026 15:27:02 GMT Subject: Re: [PATCH v2] worktree list: add --branch to select worktrees by branch Message-ID: In-Reply-To: Eric Sunshine writes: > If so, that potentially raises the question about how such filter > options should combine. It's obvious that multiple > `--filter=branch:` 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.