Re: git-rebase skips automatically no more needed commits
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 7, 2011, 16:29 UTC
- Message-ID
- <7vk49k48q4.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CAC9WiBi_bkLNJZckq2fr3eb6ie+KVfauE_PyA3GcaW5Ga-isFw@mail.gmail.com>
Francis Moreau <francis.moro@gmail.com> writes:
Show 9 quoted lines
> 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.