From: Eric Sunshine Date: Sat, 24 Oct 2026 06:25:20 GMT Subject: Re: [RFC PATCH 1/1] worktree list: add --merged and --no-merged Message-ID: In-Reply-To: On Fri, Oct 23, 2026 at 2:30 PM Junio C Hamano wrote: > Jasper Mayone writes: > > 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 `.