Re: why "git rebase" searching the duplicate patches in <upstream branch> rather than in <new base branch>?

Sergey Organov [off-list ref] writes:

Similar problem should exist for explicitly specified <upstream> that
might happen to have little in common with the current <branch>, right?

I do not think so.  Plain-vanilla rebase is to carry forward our
changes on top of updated upstream, which means that there is

            x--x--x (side)
           /
   ---o---o---o---o---o---o (upstream)
          ^
       (old upstream)

inherently ancestry relationship between the old upstream and the
current upstream when rebasing 'side' to 'upstream'.

I don't actually like this.

You do not have to ;-) because I was not suggesting to change any
existing behaviour.  It was merely me thinking aloud, how I might
do the feature if I were designing it from scratch now.

Overall, it seems that we should take the <newbase> rather than
<upstream> (that is still <upstream> when --onto is not specified), and
apply the skipping logic from there, to whatever depth the merge-base
will give us. If it's already implemented this way, then only the manual
page needs to be fixed.

Sounds sensible.  I didn't check what the actual code does ;-)