From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Thu, 08 Oct 2026 17:51:47 GMT
Subject: Re: [PATCH] branch: let --delete-merged find squash merged branches
Message-ID: <CALnO6CB2qPtv6Cr4LL1x=ZPmD_zLw1GzLUKgXE-NcTWObbiLkA@mail.gmail.com>
In-Reply-To: <39a28064-1698-4971-a80f-4a4c4dcdd8d9@gmail.com>

On Sun, Oct 4, 2026 at 5:54 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
>
> On 29/09/2026 12:26, D. Ben Knoble wrote:
> > On Tue, Sep 29, 2026 at 3:33 AM Harald Nordgren via GitGitGadget
> > <gitgitgadget@gmail.com> wrote:
> >
> > …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)
>
> That's what I was expecting as well. It would be worth carefully
> studying the implementation of git-cherry. "git cherry A...B"
> precalculates the patch-ids from the side of the merge base that has the
> fewest commits and then walks the other side to compare them. While it
> is walking the other side I think it also looks at which paths were
> changed to avoid calculating the patch-id for commits that cannot match.
> It also batches fetches the blobs it needs in partial clones.
>
> As far as I can see the implementation here makes a separate upstream
> revision walk for each branch, and recalculates the upstream diffs each
> time which seems less efficient than it could be.

Thanks for spelling that out!

> > 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).
>
> Yes if a branch has been rebased before it is merged it may be altered
> such that we cannot detect it.

Yep. I'm not sure what Harald (or we) would want to do here.
git-range-diff has trouble detecting these scenarios today, so maybe
matching that and later finding a way to improve is ok.

> > 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.
>
> If we have
>
> (topic)  D - C - B - A
>                        \
>   (main)    M - Q - P - O -
>              \          /
>                - - S - -
>
> where M is a squashed merge of topic I think we have
>
>      M^2^{tree} == topic^{tree}
>      Merge-base(M^1, M^2) == Merge-base(topic, topic@{upstream})
>      $(git rev-list --count --right-only M^1...M^2) == 1

Perhaps we are thinking of 2 different things? In practice when I see
a merge created using GitHub's squash and merge option (and, I think,
also when using `merge --squash`), there is no second parent. You
could instead just get

    (main) S - Q - P - O

where S is A+B+C+D applied to Q (i.e., closer to a cherry-pick with
--no-commit).

And we know that S is not necessarily tree-same to topic's D, so…?

-- 
D. Ben Knoble