From: Junio C Hamano Date: Thu, 22 Oct 2026 16:33:23 GMT Subject: Re: [PATCH v3 0/3] branch: let --delete-merged find squash merged branches Message-ID: In-Reply-To: Harald Nordgren writes: > So do we go with `--delete-irrelevant` or > `--delete-irrelevant=squashed,rebased` to give us two levels here? I'd > rather do the former. Two comments. * Naming I would avoid a negative-sounding word like "irrelevant". Your work is almost always relevant, at least to you. The purpose of the new feature is to find branches that the user no longer needs to keep because they have been practically merged. Perhaps --delete-integrated? I do not know. The naming matters, and I hope somebody watching from the sidelines can suggest a better alternative. For lack of a better alternative that I can suggest, I will use "--delete-foo" for the remainder of this message. * Option value 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. 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? Thanks.