Re: [PATCH v3 0/3] branch: let --delete-merged find squash merged branches

From: Jasper Mayone <me@jaspermayone.com>
Date: Oct 22, 2026, 17:44 UTC
Message-ID: <20261022174429.81186-1-me@jaspermayone.com>
In-Reply-To: <CAHwyqnUWab7AhqJtWkPQzw_dh+OwxiZxt2+1TTC-r+VPx+20Tg@mail.gmail.com>

Harald Nordgren <haraldnordgren@gmail.com> writes:

> I'm leaning toward `--delete-merged[=<level>]`. But it's good that you
> are pointing this out. It's tempting to unify it like that.

The value of --delete-merged is already taken by the upstream <pattern>, and it is required. So "--delete-merged=squashed" already means "branches whose upstream is a ref called squashed" today, and it cannot also carry a level without breaking that.

> I like `integrated` a lot.

+1 from a user who lands most work with "Squash and merge". It is the word our documentation already uses, and it does not say how the work got there, which fits every level of the ladder.

Since the value slot holds the pattern, the level needs its own place. One shape that keeps each command line simple:

    git branch --delete-merged <pattern>       # strict, as today
    git branch --delete-integrated <pattern>   # rebased and squashed too

with a config variable if someone wants the middle step of Junio's ladder (merged, then rebased, then squashed) as the meaning of --delete-integrated.

On the false positive: Ben's "npm update" case, Junio's new test and my case are the same thing. The upstream commit has the right contents but was written by someone else. The squash and rebase buttons keep the author of the pull request on the upstream commit, so requiring that the landing commit's author also authored a commit on the branch would reject all three. Work that a maintainer applied with "git am" would still count, because "git am" keeps the author too. I have not measured this, so take it as an idea to try.

Thanks, Jasper