Re: [PATCH v3 0/3] branch: let --delete-merged find squash merged branches
- From
Harald Nordgren <haraldnordgren@gmail.com>
- Date
- Oct 22, 2026, 14:41 UTC
- Message-ID
- <CAHwyqnXYopD8=KFGdYkaqwCdm8q548QOKnyjm7SSRUqGXkOxEA@mail.gmail.com>
- In-Reply-To
- <CALnO6CC0+t3PTVXC=TohzpqzgeOK4t9bKzGP-43uD1bbA4dPOg@mail.gmail.com>
On Thu, Oct 22, 2026 at 2:56 PM D. Ben Knoble <ben.knoble@gmail.com> wrote:
Show 21 quoted lines
> > On Wed, Oct 21, 2026 at 2:52 PM Harald Nordgren > <haraldnordgren@gmail.com> wrote: > > 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. > > I have seen this happen when 2 PRs contain the same "npm update" > commits and are rebased onto main: whoever gets there first wins. If > the commits contained additional changes, then the later-rebased > commit loses some changes because they were handled prior, but (when > doing so via GitHub) the commit message is unchanged. I find this a > bit confusing, tbh! > > But, I will say it is rare. Perhaps not "extremely" :) > > -- > D. Ben Knoble
Good counter example!
But it would have to be something like that then: an automated deterministic script.
Harald