Re: [PATCH v2 0/2] branch: let --delete-merged find squash merged branches

[Phillip Wood <phillip.wood123@gmail.com>]

On 12/10/2026 01:30, Junio C Hamano wrote:
> "Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> 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.

I think it would be helpful if the cover letter explained in more detail 
what this series actually does to detect squashed merges and compared 
that to other approaches such as using patch ids or test merges. As far 
as I can see the approach here is, to a first approximation, checking

	$(git merge-tree B C) == C^{tree}

to see if C is a squashed merge of B, only without using merge-ort but 
by calling merge_ll() on each path instead. That means we're not 
checking if C is the same as merging B into C^, C may contain additional 
changes as well. I think it also means we're missing out on rename 
detection. It would be good to get a clear idea of what the tradeoffs of 
the various approaches are before any more code is written.

Thanks

Phillip

>>   * 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.