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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 20, 2021, 15:36 UTC
Message-ID: <xmqqczrdhu9q.fsf@gitster.g>
In-Reply-To: <87a6mhgxv4.fsf@osv.gnss.ru>

Sergey Organov <sorganov@gmail.com> 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.

Show 5 quoted lines

> 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 ;-)