Re: git-rebase skips automatically no more needed commits

From: Francis Moreau <francis.moro@gmail.com>
Date: Sep 8, 2011, 07:10 UTC
Message-ID: <CAC9WiBjMUg3SUOP9AJw6qCKrGVLs6Qy_O2fQa_SHX30NkjAEdw@mail.gmail.com>
In-Reply-To: <7vk49k48q4.fsf@alter.siamese.dyndns.org>

On Wed, Sep 7, 2011 at 6:29 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 14 quoted lines

> Francis Moreau <francis.moro@gmail.com> 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,

But is it the common case ? That would mean that A and B are part of totaly independant branches which is not that common I think.

I'm using "git rebase --onto A B C" because I want to simplify git's work. I know that any commits between A..B are already in A history and I'm not interested in rebasing them anyways.

Show 7 quoted lines

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

Hmm I dont understand why "rebase --onto A B C" wouldn't try to find the merge base between A and B. If it doesn't (which is quite uncommon I guess) then don't do the filtering as we're currently doing but if there's a merge base (common case) then do the filtering.

No ?

-- 
Francis