From: Jasper Mayone Date: Thu, 29 Oct 2026 04:46:33 GMT Subject: Re: [PATCH v2] worktree list: add --branch to select worktrees by branch Message-ID: <20261029044633.12429-1-me@jaspermayone.com> In-Reply-To: "Kristoffer Haugsbakk" writes: > git-for-each-ref(1) (and git-branch(1) etc.) have `worktreepath`. > > git worktree add ../test-branch > git worktree remove $(git for-each-ref \ > --format='%(worktreepath)' refs/heads/test-branch) > git branch -d test-branch > > It will not list the worktree path if that branch is being rebased. Thanks, I had missed %(worktreepath). With it, what I wanted from the start is already one command: git for-each-ref --merged origin/main \ --format='%(worktreepath)' refs/heads/ So --branch adds little on top of that. The one real gap is the one you name. While a branch is being rebased or bisected, %(worktreepath) is empty, "git branch" does not mark it with "+", and "git worktree list" shows that worktree as "(detached HEAD)". Yet "git worktree add" and "git branch -d" already treat that branch as checked out. As Phillip pointed out, branch.c already has this information: branch_checked_out() covers a plain checkout, a rebase, a bisect and "rebase --update-refs". So I would like to drop --branch and instead make %(worktreepath) use the same information, so that it names the worktree of a branch that is being rebased or bisected. That is a smaller change with no new option, so the naming question Eric raised and the --filter-command idea Junio floated do not come up. Is that change in behavior acceptable? A script that reads %(worktreepath) would now get a path for a branch that is being rebased. I think that is a fix, since the rest of Git already considers that branch checked out, but I would like to hear if anyone relies on the empty value. Phillip, thank you for the review. Your point that "git worktree list" output does not say which entry is the main worktree still stands, and I can send that as a separate patch if it is wanted. Thanks, Jasper