On Thu, 8 Sep 2011, Francis Moreau wrote: > On Wed, Sep 7, 2011 at 6:29 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Francis Moreau <francis.moro@xxxxxxxxx> 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. 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html