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

From: Harald Nordgren <haraldnordgren@gmail.com>
Date: Oct 22, 2026, 17:44 UTC
Message-ID: <CAHwyqnUpheti76YJSn4h___fNZr52PzPQq0pQvA8KNyuoanxGQ@mail.gmail.com>
In-Reply-To: <xmqqa4o5itkc.fsf@gitster.g>

> I would avoid a negative-sounding word like "irrelevant".  Your work
> is almost always relevant, at least to you.

Yes :-D

> Another point is that different kinds of detection should probably
> form subset-superset relationships, rather than a Venn diagram, to
> make them easy to understand and useful.

Show 5 quoted lines

> When you specify --delete-foo=squashed,rebased, do you expect that a
> branch that would be removed by --delete-merged (i.e., merged as
> identical commits) would be kept because it was not squash-merged
> or rebased onto the upstream?  I doubt users would want to make such
> a distinction.

Very important point regarding the design.

Show 13 quoted lines

> I do not personally care about the distinction between rebasing and
> squash-merging, but users probably do.  I suspect they expect that a
> mode catching squash-merged branches would also recognize a branch
> that was straight cherry-picked (or rebased) upstream.
>
> Perhaps the options could be structured like this to be as easy to
> understand as possible:
>
>     --delete-foo=merged      Same as --delete-merged.
>     --delete-foo=rebased     Above, plus rebased.
>     --delete-foo=squashed    Above, plus squash-merged.
>
> Would this be a clearer way to present the feature to users?

Yes, but we can do better on naming, something in this direction?

     --delete-foo=match-hash     #Same as --delete-merged.
     --delete-foo=match-commits  #Above, plus rebased.
     --delete-foo=match-content  #Above, plus squash-merged.

This comes to mind (https://git-scm.com/docs/git-push#Documentation/git-push.txt-pushdefault), different `push.default` options can overlap or subsume each other, and it's also clear that only one will be used at a time.

Harald