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

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Oct 28, 2026, 06:02 UTC
Message-ID: <CAPig+cT6rxKptqSEKuVbi2FafBqh+DfcHAkHfz2-=SH3y2hfyw@mail.gmail.com>
In-Reply-To: <e08fd267-7017-493f-8f1b-d8dfb568b5fd@gmail.com>

On Sun, Oct 25, 2026 at 10:47 AM Phillip Wood <phillip.wood123@gmail.com> wrote:

Show 9 quoted lines

> On 24/10/2026 17:53, Jasper Mayone wrote:
> > A worktree that is rebasing or bisecting a branch
> > counts as having it checked out, as it does for "git branch -d" and
> > "git worktree add". <branch> is a branch name, or a full name under
> > refs/heads/.
>
> That's useful because "git worktree list" does not show branch names
> when they're being rebased or bisected. The commit message should spell
> that out.

Aside from Philip's excellent review comments, I have a relatively minor question:

Rather than naming it `--branch`, under the assumption that users may eventually want to filter on other worktree properties, should this new option be given a more generic name, such as `--filter=branch:<name>`?

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.