Re: [PATCH] branch: let --delete-merged find squash merged branches

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Sep 29, 2026, 11:26 UTC
Message-ID: <CALnO6CBwWy3aafyDJPKFk5vuWy2EF1n1Oc=W7+RVAE3rxpXwiw@mail.gmail.com>
In-Reply-To: <pull.2425.git.git.1790667030497.gitgitgadget@gmail.com>

Without looking too much further…

On Tue, Sep 29, 2026 at 3:33 AM Harald Nordgren via GitGitGadget <gitgitgadget@gmail.com> wrote:

Show 21 quoted lines

>
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Branches merged on GitHub with "Squash and merge" or "Rebase and
> merge" are never deleted by "git branch --delete-merged". The upstream
> holds a rewritten copy of their work, so their tips are not reachable
> from it and they look unmerged forever.
>
> Treat such a branch as merged when some upstream commit since the fork
> point contains all of its changes, so that merging the branch into
> that commit would change nothing. Name that commit in the output so
> the user can see where the work went:
>
>     Deleted branch topic (was 1a2b3c4, landed as 9f8e7d6).
>
> The first upstream commit that contains the changes is used, so the
> branch is deleted even if upstream later reverted or reworked them.
> Nothing is lost, since that commit keeps them in the upstream history.
> A branch whose changes only partly landed is kept.
>
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>

…in the rebase case, I would expect something like git-log's --cherry-mark option (or really the algorithm behind it, git-cherry, and git-range-diff) to be useful for identifying rebased branches. But of course even rebase-merged branches can end up with minor differences (say, a commit was made upstream before that branch was rebased with an identical change; no conflict occurs, but the new commit differs from the old by not having that change).

In the squash case, I suppose the best we can do is check that all our changes were applied at some point between the merge-base and the tip. There probably won't be any tree-same commits, though maybe a (premature?) optimization can return early if the trees match exactly.

It looked like you don't distinguish the 2 cases in the code, and I think that's reasonable: we wouldn't know a priori whether to check for a rebased series or a squashed commit, so we'd have to run both checks, and the latter presumably subsumes the former.

Anyway, I can see how this would all be fairly expensive---on one repo I work in, git-range-diff can be somewhat slow depending on how many commits are in the range, I think. I don't know if it's worth trying to state that for folks, though? If we ever make improvements to performance, we'd have to remember to remove the "this may be slow" text.

> After the release of 2.56, I saw people liking the --delete-merged
>    feature, but asking for this. A lot of people, me included prefer
>    squash-merge and it currently doesn't work with --delete-merged.

Btw, I wonder if you can share where you saw this? 2.56 was released so recently I'm (pleasantly) surprised there's already feedback on this!

-- 
D. Ben Knoble