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.
On Wed, Sep 7, 2011 at 6:29 PM, Junio C Hamano [off-list ref] wrote:
Francis Moreau [off-list ref] writes:
quoted
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.
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
On Thu, 8 Sep 2011, Francis Moreau wrote:
On Wed, Sep 7, 2011 at 6:29 PM, Junio C Hamano [off-list ref] wrote:
quoted
Francis Moreau [off-list ref] writes:
quoted
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.
Patches that are in both sides of v2.6.39...foo will be filtered, but
as Junio said, what is in master is not considered. In your case,
since foo was created from the tag, there should of course be no
commits in foo..v2.6.39.
I'm using "git rebase --onto A B C" because I want to simplify git's
work.
What work? Calculating mege-base and patch-ids? But that's exactly
what you said you don't want to avoid, no?
I know that any commits between A..B are already in A history
Did you mean "B..A" here?
and I'm not interested in rebasing them anyways.
They wouldn't be rebased by running "git rebase A C" either... Maybe
I'm misunderstanding something.
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.
It could do that. I think that's what Junio meant by "justifiable--- I
dunno". In your case, though, it seems like "git rebase master foo"
would do exactly what you want.
Somewhat related, I think "git rebase --onto A B C" should NOT filter
out patches that also appear both sides of "B...C", because when
"--onto" is used, "B" is only used as a way to calculate the
merge-base. I think it would make more sense to filter out from
appears in both "B..C" what also appears in "C..A". This has been on
my todo list for way too long. Some day I'll send out a patch for it
and we'll see what others think.
Martin