From: D. Ben Knoble Date: Tue, 29 Sep 2026 11:26:20 GMT Subject: Re: [PATCH] branch: let --delete-merged find squash merged branches Message-ID: In-Reply-To: Without looking too much further… On Tue, Sep 29, 2026 at 3:33 AM Harald Nordgren via GitGitGadget wrote: > > From: Harald Nordgren > > 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 …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