Re: [PATCH v3 0/3] branch: let --delete-merged find squash merged branches

From: Jasper Mayone <me@jaspermayone.com>
Date: Oct 21, 2026, 17:35 UTC
Message-ID: <20261021173503.70887-1-me@jaspermayone.com>
In-Reply-To: <pull.2425.v3.git.git.1792585717.gitgitgadget@gmail.com>

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 7 quoted lines

>  * By default a branch counts as merged when an upstream commit has its
>    exact version of every file it changed. This never reads file contents,
>    so it stays cheap in a partial clone. It finds rebase merges, and squash
>    merges where upstream left those files alone.
>  * Replace --no-squashed with an opt-in --squashed, which also finds
>    branches merged after upstream changed the same files by merging those
>    files.

Thanks for the new round. I ran v3 (2befb182dc) on the same generated repositories as v2, and added one case for a squash that landed after upstream changed another line of the same file. t3200 passes, and the build is clean with DEVELOPER=1.

The results match the cover letter. Without --squashed, v3 deletes the squash merges, the GitHub-style squash, the rebase merge, the rename, and the squash that was later reverted. It keeps the new case. --squashed also deletes the new case, and "landed as" names the correct commit each time. A branch whose work only partly landed is kept, with or without --squashed.

But the false positive from my v2 report is still there. A branch that was never merged is deleted because another author made the same change in an unrelated commit. In v2 I could turn that off with --no-squashed. In v3 the cheap check finds it, so it happens with no option at all.

That is the case Junio called "irrelevant", and he suggested that "--delete-merged" stay the strict "my commits are in upstream" check. The file contents of such a branch are in upstream, but its own commits and messages are not, and the user did not ask for the looser meaning.

So I would still prefer the whole looser check behind one opt-in, with a config variable for the default. The cheap check and --squashed could then be two levels of that one option, for example:

    git branch --delete-merged origin/main --landed=files
    git branch --delete-merged origin/main --landed=merge

Users who land everything through "Squash and merge" set it once in the config, and plain --delete-merged keeps its current meaning.

A branch checked out in a worktree is still skipped with no message, while a branch with deleteMerged=false prints "Skipping". I sent an RFC for "git worktree list --merged" about that case:

  https://lore.kernel.org/git/20261021173350.67854-1-me@jaspermayone.com/

Thanks, Jasper