Re: [PATCH v2 0/2] branch: let --delete-merged find squash merged branches

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 13, 2026, 02:23 UTC
Message-ID: <xmqqy0c21gq1.fsf@gitster.g>
In-Reply-To: <CAHwyqnUP72njKKap16u+kShHmhssiUXFUVRhURPP_wzwZsvtdg@mail.gmail.com>

Harald Nordgren <haraldnordgren@gmail.com> writes:

Show 11 quoted lines

>> At least the one-to-one part of the operation should learn from what
>> Dscho did in range-diff
>
> Oh, that's great! I'll take a look.
>
>> especially the part that does take
>> similarity of the log messages and authorship information, instead
>> of paying attention only to patch IDs.
>
> Right, authorship would at least be a good filter to speed things up,
> can't be the same commit if it has two different authors!

After thinking about it a bit more, I no longer am sure.

It eventually boils down to what we are trying to achieve with this option, but "I have these pending works I asked upstream to take a look, I want to see which ones landed and remove them from my local copy of the project" and "I have these pending works, but upstream has been collecting improvements from many other people in addition to me. I want to see which ones are still relevant" are overlapping but different. And I think when you start talking about rebasing and squash merging, you are asking "is my copy still relevant?"

And the latter is strict superset of the former.

You might have instructed your agent to write a two patch series and asked upstream to pull. Somebody else used the same AI-gen and created one patch that solves the same problem, which happened to have landed first. Or that somebody may have sent their solution in two patches similar to yours. In either case, your two patch series is now irrelevant. You would want to drop your branch that is no longer relevant, regardless of whose work made it irrelevant,

They may be textually similar enough that we can tell mechanically that there are already the same or similar code in the place you were trying to touch. "--delete-irrelevant" would remove your local copy. There may be salvageable bits (e.g., yours may have updates to documentation and tests that theirs lacks), so if we can detect a case where only some parts of your work has become irrelevant, that would be very useful, too.

Stepping back a bit, perhaps "--delete-merged" should not be modified to touch anything that was rebased, cherry-picked, or squash merged. It is good to have one stable and strict "if my commits were merged and safely saved there, delete them from here", regardless of how much looser definition of "the same patch" is used for "--delete-irrelevant".