Sergey Organov <sorganov@xxxxxxxxx> 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 ;-)
