Git development
 help / color / mirror / Atom feed
* [RFC PATCH 0/1] worktree list: add --merged and --no-merged
@ 2026-10-21 17:33 Jasper Mayone
  2026-10-21 17:33 ` [RFC PATCH 1/1] " Jasper Mayone
  2026-10-21 21:36 ` [RFC PATCH 0/1] worktree list: add --merged and --no-merged Harald Nordgren
  0 siblings, 2 replies; 11+ messages in thread
From: Jasper Mayone @ 2026-10-21 17:33 UTC (permalink / raw)
  To: git; +Cc: gitster, haraldnordgren, sunshine, ben.knoble, Jasper Mayone

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


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2026-10-26 11:02 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-21 17:33 [RFC PATCH 0/1] worktree list: add --merged and --no-merged Jasper Mayone
2026-10-21 17:33 ` [RFC PATCH 1/1] " Jasper Mayone
2026-10-23 18:30   ` Junio C Hamano
2026-10-24  6:25     ` Eric Sunshine
2026-10-24 16:53       ` [PATCH v2] worktree list: add --branch to select worktrees by branch Jasper Mayone
2026-10-25 14:47         ` Phillip Wood
2026-10-26 11:02           ` Phillip Wood
2026-10-21 21:36 ` [RFC PATCH 0/1] worktree list: add --merged and --no-merged Harald Nordgren
2026-10-21 22:12   ` Junio C Hamano
2026-10-22  7:21     ` Harald Nordgren
2026-10-22 17:58   ` Kristoffer Haugsbakk

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox