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

[Junio C Hamano <gitster@pobox.com>]

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

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