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

[Jasper Mayone <me@jaspermayone.com>]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> 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