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

From: Jasper Mayone <me@jaspermayone.com>
Date: Oct 19, 2026, 04:40 UTC
Message-ID: <20261019044005.99247-1-me@jaspermayone.com>
In-Reply-To: <xmqqy0c21gq1.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 6 quoted lines

> Stepping back a bit, perhaps "--delete-merged" should not be
> modified to touch anything that was rebased, cherry-picked, or
> squash merged.  It is good to have one stable and strict "if my
> commits were merged and safely saved there, delete them from here",
> regardless of how much looser definition of "the same patch" is used
> for "--delete-irrelevant".

I am in the group of users this series is for. Most repositories I work in land pull requests with GitHub's "Squash and merge". I built v2 (ec88bde252) and tested it on generated repositories. The results support keeping the strict meaning as the default.

v2 did what it says for squash merges, GitHub-style squashes with a new message and committer, rebase merges, renames, and squashes that were later reverted. "landed as" named the correct commit every time. It kept a branch whose work only partly landed.

But it also deleted a branch that was never merged. Another author had made the same change upstream in an unrelated commit, and v2 reported the branch as "landed as" that commit. That is the "irrelevant" case from your message, and today v2 handles it the same way as a squash merge of my own work.

So I agree that the strict meaning should stay the default. I also want to turn the looser check on once per repository and then forget about it. Something close to what Ben suggested earlier would do that:

    git branch --delete-merged origin/main --landed=squash

plus a config variable for the default. A third kind of integration then becomes one more value, not one more --no-<kind> option.

On speed: with 3056 commits and 80 branches, v2 took 0.078s against 0.030s for 2.56.0, and --no-squashed brought it back to 0.030s. In a blobless clone the first run took 0.42s and fetched 13 blobs. --no-squashed fetched none.

One more point. A branch checked out in a worktree is skipped with no message, but a branch with deleteMerged=false prints "Skipping". I keep one worktree per pull request, so most of my merged branches are skipped silently. A "Skipping 'topic' (checked out in <path>)" line would help. I plan to send a separate RFC for "git worktree list --merged", so it would also help if the "has this branch landed?" check were a helper that worktree code can call.

Tested-by: Jasper Mayone <me@jaspermayone.com>

Thanks, Jasper