From: Jasper Mayone Date: Wed, 21 Oct 2026 17:35:03 GMT Subject: Re: [PATCH v3 0/3] branch: let --delete-merged find squash merged branches Message-ID: <20261021173503.70887-1-me@jaspermayone.com> In-Reply-To: "Harald Nordgren via GitGitGadget" writes: > * 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