From: Harald Nordgren Date: Wed, 21 Oct 2026 18:51:43 GMT Subject: Re: [PATCH v3 0/3] branch: let --delete-merged find squash merged branches Message-ID: In-Reply-To: <20261021173503.70887-1-me@jaspermayone.com> > 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. My sincere apology for skipping over your post before. My branch being pruned because someone else did the same thing would indeed feel weird. And it could be stopped by doing an author check. But I question if it’s realistic at all. The code has to be exactly the same, and I don’t think I have ever seen that happen, I would call this an extremely rare edge case. And if it did happen and it was *incorrectly* pruned, it is still not completely lost, because by definition it is in the upstream already. So why would you actually need that branch? (But it won’t happen) > 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. I think this is pushing it in terms of UX mental load. I will never run this check without specifying the highest level of pruning. I also have another topic open to be able to skip the '**' pattern. It's about giving users the simplest-to-use tool to work with, not endless configurability for a command that just deletes merged branches. > 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/ I'll take a look at that after sending this, I haven't yet. Thanks in advance! Harald