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