Git may teach --delete-merged to spot squash merges

A proposed change to Git would make git branch --delete-merged remove local topic branches that upstream already took via squash or rebase, the integration styles used by GitHub's "Squash and merge" and "Rebase and merge" buttons and by git merge --squash.

Today the option only deletes a branch when its tip is reachable from the configured upstream. Squash and rebase rewrites that history, so the local tip never appears on upstream and the branch looks unmerged forever. Contributors who prefer those workflows accumulate stale local branches that the existing cleanup path will not touch.

Harald Nordgren's series treats a branch as merged when some upstream commit since the fork point already contains all of its changes, so merging the branch would alter nothing. Deletion output would name that landing commit, for example "Deleted branch topic (was 1a2b3c4, landed as 9f8e7d6)". The first such upstream commit counts, even if later reverts or reworks followed; partly landed work is left alone. A companion --no-squashed switch would keep the old reachable-tip-only behavior for users who want to skip the extra search.

On the Git development list, reviewers pressed on cost and method before more code lands. Phillip Wood noted that even an efficient implementation will be slower, and that partial clones may have to fetch blobs to compare content, so an off switch and clear docs matter. He asked for an explicit comparison of detection strategies (content checks, patch ids, trial merges) and warned that a pure "already contains the changes" test can point "landed as" at a commit that also carries unrelated work, and can mishandle renames.

Git maintainer Junio C Hamano called the goal interesting but questioned folding one-to-one rebase matching into a general squash search. He suggested learning from range-diff's handling of rewritten commits, including log-message and authorship similarity rather than patch identity alone, and doubted a single default that piles on variants with optional disables will stay extensible when selective cherry-picks and other non-preserving integrations appear. Nordgren argued that matching on commit messages is brittle under hosting-site squash rewriting, preferred comparing the actual changes, and sketched splitting rebase detection, squash detection, and the opt-out into separate steps.

The work remains under review; no release decision has been announced.