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

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Oct 12, 2026, 15:49 UTC
Message-ID: <CALnO6CDTaXcfDArqT3tj3fY5hReEcAaMmCbTD9fpMJdbCMc-bA@mail.gmail.com>
In-Reply-To: <CAHwyqnV=SBMwTzC74YN7585u_pd525E=tRArL_5z_uLb-FGnhg@mail.gmail.com>

On Mon, Oct 12, 2026 at 8:42 AM Harald Nordgren <haraldnordgren@gmail.com> wrote:

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

Well, I think Junio was talking about the rebase cases for log messages, but I have been known to cherry-pick and edit the log message of small contributions that aren't up to my personal standards to help contributors land their changes, in which cases you *would* care more about patch ID than log message.

-- 
D. Ben Knoble