Re: git-rebase skips automatically no more needed commits

Francis Moreau [off-list ref] writes:

If I start the rebase process with : "git rebase -i -p master foo"
then the filtering is happening. Here 'foo' has been created with
v2.6.39 tag as start point and contains some patches cherry-picked
from the upstream.

However if I call git-rebase this way: "git rebase -i -p --onto master
v2.6.39 foo", then it seems that no filtering is done.

Is that expected ?

Because "rebase --onto A B C" has to be usable when commit A does not have
any ancestry relationship with the history between B and C, I wouldn't be
surprised if the command does not look at commits on the history that lead
to A that _might_ be related to the ones between B and C. It does not know
how far to dig from A and stop, and obviously you do not want to dig down
to the beginning of the history. "rebase A B" on the other hand can safely
stop digging the history back from A down to where the history leading to
B forked (i.e. merge base between A and B).

I do not know if "expected" is the right adjective; understandable---yes,
unsurprised---yes, justifiable--- I dunno.