Am 5/29/2013 8:39, schrieb Martin von Zweigbergk: > +# f > +# / > +# a---b---c---g---h > +# \ > +# d---G---i > +# \ \ > +# e-------u > +# > +# uppercase = cherry-picked > +# h = reverted g > +test_expect_failure "rebase -p --onto in merged history does not lose patches in upstream" " > + reset_rebase && > + git rebase -p --onto f h u && > + test_cmp_rev f HEAD~3 && > + test_revision_subjects 'd G i e u' HEAD~2 HEAD^2^ HEAD^2 HEAD^ HEAD > +" My expectations are different: When a patch is in upstream, then it is not to be rebased, even --onto somewhere else than upstream. But take this with a grain of salt, as I never encounter(ed) this use-case in practice. > +test_expect_success "rebase -p --onto in merged history drops patches in onto" " > + reset_rebase && > + git rebase -p --onto h f u && > + test_cmp_rev h HEAD~3 && > + test_revision_subjects 'd i e u' HEAD~2 HEAD^2 HEAD^ HEAD > +" And this is just the opposite case, where I think the patch should be kept. > +# a---b---c > +# \ > +# d---e > +# \ \ > +# n---r > +# \ > +# o > +# > +# r = tree-same with n > +# uppercace = cherry-picked I do not see any upper-cased letters in this graph. ;) > +test_expect_success "rebase -p re-creates empty internal merge commit" " > + reset_rebase && > + git rebase -p c r && > + test_revision_subjects 'c d e n r' HEAD~3 HEAD~2 HEAD^2 HEAD^ HEAD Again, check c with test_cmp_rev. -- Hannes -- 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