From: Junio C Hamano Date: Mon, 12 Oct 2026 00:30:00 GMT Subject: Re: [PATCH v2 0/2] branch: let --delete-merged find squash merged branches Message-ID: In-Reply-To: "Harald Nordgren via GitGitGadget" writes: > Branches merged on GitHub with "Squash and merge" or "Rebase and merge" are > never deleted by git branch --delete-merged, because their tips are not > reachable from the upstream. This treats such a branch as merged when some > upstream commit contains all of its changes, and names that commit in the > output: > > Deleted branch topic (was 1a2b3c4, landed as 9f8e7d6). Interesting. After rebasing, you probably can (re)use the same algorithm as used in range-diff to match the commits and their rewritten counterparts, but I wonder how "squash" would go. Presumably you can locally make a trial squash merge and probe for a similar commit on the upstream commit. On the other hand, unlike deliberate rebasing done during a patch iteration, rebase done on the upstream to integrate your changes would not rewrite the log messages, so matching the commits based on the log message may work better than a range-diff between iteration vN and v(N+1) in the submitted patches. > * Diff each upstream commit once and share the result between all branches, > faster than v1. > * Fix a branch merged with a merge commit being reported as "landed as" the > merge when another branch was searched first, and add a test for it. Show > the topic commit itself in "landed as" for work that arrived through a > merge. > * Use git merge --squash as the example in the commit message and mention > GitHub's squash and rebase buttons. > * Add --no-squashed to skip the squash search. > > Harald Nordgren (2): > branch: let --delete-merged find squash merged branches > branch: add --no-squashed to skip the squash search This a bit unexpected two-patch organization; I would have expected that the cases where our side and upstream side should correspond one-to-one (i.e., what you call rebase-and-merge) and other cases (i.e., squash merge) to require very different matching algorithm, which would lead to two-patch organization where one adds support for rebase and the other adds support for squash.