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

[Junio C Hamano <gitster@pobox.com>]

Harald Nordgren <haraldnordgren@gmail.com> writes:

>> 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".