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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 23, 2026, 18:30 UTC
Message-ID: <xmqqqzhg5kyd.fsf@gitster.g>
In-Reply-To: <20261021173350.67854-2-me@jaspermayone.com>

Jasper Mayone <me@jaspermayone.com> writes:

Show 6 quoted lines

> 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.