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

I keep one worktree per topic. When a topic lands, its branch stays checked out in that worktree, so "git branch --delete-merged" skips it, and there is no direct way to ask which worktrees are done. In the --delete-merged squash thread [1] I said I would send an RFC for this. Here it is.

This patch teaches "git worktree list" the --merged and --no-merged filters that "git branch", "git tag" and "git for-each-ref" already have, applied to the HEAD of each worktree:

    $ git worktree list --merged origin/main
    /src/proj            1a2b3c4 [main]
    /src/proj-topic-a    5d6e7f8 [topic-a]
    /src/proj-fix-b      9a8b7c6 (detached HEAD)

It only lists. Removing stays a separate step with "git worktree remove", which already refuses a dirty or locked worktree and the main worktree, so a script can do:

    git worktree list --porcelain --merged origin/main |
    sed -n "s/^worktree //p" |
    while read -r wt; do git worktree remove "$wt"; done

The test is strict reachability, the same as "git branch --merged". A worktree whose topic was squash or rebase merged upstream is not listed. If Harald's "has this landed" check ends up as a helper, a later option could use it here too, but I kept that out of this RFC.

Questions for the list:

 1. The main worktree is filtered like any other, so it is usually
    listed. "git branch --merged" also lists the current branch, so
    I kept that. Should it be left out instead?

 2. The commit defaults to HEAD, like the ref filters. For cleanup,
    each worktree's branch upstream would often be the more useful
    default, but that is a different meaning for the same option
    name. Is HEAD the right default?

 3. I reused struct ref_filter and OPT_MERGED from ref-filter.h, so
    the parsing, the default and the error messages match the other
    commands. It only needs the two commit lists. Is that acceptable,
    or would you prefer a small local option callback? If the reuse
    is fine, --contains and --points-at could follow the same way.

 4. Is a later "git worktree remove --merged <commit>" (with
    --dry-run) wanted, or should removal stay in scripts?

[1] https://lore.kernel.org/git/pull.2425.v3.git.git.1792585717.gitgitgadget@gmail.com/

Jasper Mayone (1):
  worktree list: add --merged and --no-merged

 Documentation/git-worktree.adoc |  24 +++++-
 builtin/worktree.c              |  80 +++++++++++++++++++-
 t/t2402-worktree-list.sh        | 125 ++++++++++++++++++++++++++++++++
 3 files changed, 226 insertions(+), 3 deletions(-)

base-commit: 47fdf2208c5b94c8cc01c106b8f7c85efb91c926