From: Harald Nordgren <haraldnordgren@gmail.com>
Date: Thu, 22 Oct 2026 17:44:08 GMT
Subject: Re: [PATCH v3 0/3] branch: let --delete-merged find squash merged branches
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.

> 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.

> 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