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

From: Harald Nordgren <haraldnordgren@gmail.com>
Date: Oct 12, 2026, 12:41 UTC
Message-ID: <CAHwyqnV=SBMwTzC74YN7585u_pd525E=tRArL_5z_uLb-FGnhg@mail.gmail.com>
In-Reply-To: <xmqq1p9vdalz.fsf@gitster.g>

Show 11 quoted lines

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

Matching on commit messages sounds very brittle to me (GitHub mangles them on squash), and also unnecessary when we can compare the files themselves.

Show 10 quoted lines

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

Finding squashes is a superset of finding rebase merges. Although slower, which is why we need to be able to turn it off. So yes, then we need separate the code paths for squash and merge finding.

Then I'm thinking 3 commits:

    branch: let --delete-merged find rebase merged branches
    branch: let --delete-merged find squash merged branches
    branch: add --no-squashed to skip the squash merge check

Harald