Thread (14 messages) 14 messages, 6 authors, 7h ago

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

flat view

From: Eric Sunshine <hidden>
Date: 2026-10-28 06:03:07

On Sun, Oct 25, 2026 at 10:47 AM Phillip Wood [off-list ref] wrote:
On 24/10/2026 17:53, Jasper Mayone wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help