[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/ (local)

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