From: Harald Nordgren Date: Sat, 17 Oct 2026 22:23:11 GMT Subject: Re: [PATCH v2 0/2] branch: let --delete-merged find squash merged branches Message-ID: In-Reply-To: > 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. I would be very surprised if my branch gets deleted because someone else wrote *almost* the same code in parallel. I think we can achieve a lot here just by focusing on the use case of my own work being slightly mangled (squashed or merged). > 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". If my branch gets picked up by the mainline, my work there is done. I see no reason to keep the branch around anymore. How it gets picked up (squash, merged, or preserved commit hash) is not relevant then anymore. Besides, I can easily find the work again if I want, since by definition it's now in the mainline :) Harald