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

[Jasper Mayone <me@jaspermayone.com>]

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

>  * By default a branch counts as merged when an upstream commit has its
>    exact version of every file it changed. This never reads file contents,
>    so it stays cheap in a partial clone. It finds rebase merges, and squash
>    merges where upstream left those files alone.
>  * Replace --no-squashed with an opt-in --squashed, which also finds
>    branches merged after upstream changed the same files by merging those
>    files.

Thanks for the new round. I ran v3 (2befb182dc) on the same generated
repositories as v2, and added one case for a squash that landed after
upstream changed another line of the same file. t3200 passes, and the
build is clean with DEVELOPER=1.

The results match the cover letter. Without --squashed, v3 deletes the
squash merges, the GitHub-style squash, the rebase merge, the rename,
and the squash that was later reverted. It keeps the new case.
--squashed also deletes the new case, and "landed as" names the correct
commit each time. A branch whose work only partly landed is kept, with
or without --squashed.

But the false positive from my v2 report is still there. A branch that
was never merged is deleted because another author made the same change
in an unrelated commit. In v2 I could turn that off with --no-squashed.
In v3 the cheap check finds it, so it happens with no option at all.

That is the case Junio called "irrelevant", and he suggested that
"--delete-merged" stay the strict "my commits are in upstream" check.
The file contents of such a branch are in upstream, but its own commits
and messages are not, and the user did not ask for the looser meaning.

So I would still prefer the whole looser check behind one opt-in, with
a config variable for the default. The cheap check and --squashed could
then be two levels of that one option, for example:

    git branch --delete-merged origin/main --landed=files
    git branch --delete-merged origin/main --landed=merge

Users who land everything through "Squash and merge" set it once in the
config, and plain --delete-merged keeps its current meaning.

A branch checked out in a worktree is still skipped with no message,
while a branch with deleteMerged=false prints "Skipping". I sent an RFC
for "git worktree list --merged" about that case:

  https://lore.kernel.org/git/20261021173350.67854-1-me@jaspermayone.com/

Thanks,
Jasper