Re: [RFC PATCH 1/1] worktree list: add --merged and --no-merged

On Fri, Oct 23, 2026 at 2:30 PM Junio C Hamano [off-list ref] wrote:

Jasper Mayone [off-list ref] writes:

quoted

Users who keep one worktree per topic have no direct way to find the
worktrees whose work has already landed. "git branch --merged" lists
the branches, but the user then has to match each branch to a
worktree by hand, and a detached worktree has no branch to match.
"git branch --delete-merged" skips any branch that is checked out in
a worktree, so these are exactly the branches it leaves behind.

Real review on this patch never happened, it seems, perhaps because
a discussion on a side issue distracted everybody?

It looks like the intro unfairly narrows the problem space.  Even
for those users who do not use one worktree per topic do need to
find worktrees based on what branch they check out.  While I agree
that among the criteria to choose these branches to filter worktrees
on, "--merged" and "--not-merged" may be two of the most useful ones,
the feature does not have to be limited to them.

I wonder if "git worktree list --branch=...", where --branch= can be
given multiple times, is a better primitive?  With that you could do
something like

  $ git worktree list $(git branch --contains HEAD | sed -e 's/^/--branch=/')

to reuse the same machinery without any extra code.

I've been too busy lately to allocate time to the Git project, so I
didn't read the patch body and only quickly skimmed the commit
message, but I experienced the same reaction that this seems overly
special-case, and immediately thought of a more general "for-each"
sort of mechanism. The analogy which immediately comes to mind is `git
submodule foreach <command>`.