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

[Jasper Mayone <me@jaspermayone.com>]

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

> 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