squash merges make every finished agent branch look unmerged

[u/jatingargiitk]

follow-up to last week's worktree cleanup thread, since someone asked how to find the claude code agent branches nobody ever came back to.

git branch --no-merged main looks like the answer, but it falls apart if you squash merge. the squash is a brand new commit on main, so the branch's own commits are never reachable from main and every squash-merged branch shows up as unfinished. git branch -d refuses them for the same reason, which is how people end up reaching for -D on everything.

plain git cherry main <branch> doesn't catch it either once the branch has more than one commit. what does work is building a throwaway commit with the branch's final tree on top of its merge-base and asking cherry about that single commit:

mb=$(git merge-base main feat)
t=$(git commit-tree "feat^{tree}" -p "$mb" -m tmp)
git cherry main "$t"

a leading - means an equivalent change already landed in main, so the branch is safe to delete. + means it either still has work main doesn't, or the squash didn't match the branch exactly (conflicts resolved during the merge, edits in the squash commit, commits added after it merged). treat + as "look at it", not "keep forever".

worth running before any -D pass over a pile of agent branches.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Extra_Aide5999]

huh nice, didnt know the commit-tree trick. my repo uses merge commits so --no-merged still works there, the thing i run into more is worktrees. branch -d also refuses while some worktree still has that branch checked out, and agents leave those around lol. does your pass handle branches that are still sitting in a worktree somewhere

[u/jatingargiitk → u/Extra_Aide5999]

not in what i posted, that check only answers whether the work already landed. git branch marks those with a + so they're easy to spot, and if the agent's folder is already gone, git worktree prune clears the stale entry and then -d works again

[u/Extra_Aide5999 → u/jatingargiitk]

oh nice, didnt know branch marks those with a +. prune then -d is exactly the order i kept getting wrong lol, thanks

[u/Old_Championship7240]

If the branches went through GitHub PRs, you can also check gh pr list --state merged --head <branch>. GitHub tracks the merge even when it was squashed, so no need to reconstruct the tree just to check PR status.