Am 5/29/2013 8:39, schrieb Martin von Zweigbergk: > +# a---b-----------c > +# \ \ > +# d-------e \ > +# \ \ \ > +# n---o---w---v > +# \ > +# z > +#TODO: make all flavors of rebase use --topo-order > +test_run_rebase success 'e n o' '' > +test_run_rebase success 'e n o' -m > +test_run_rebase success 'n o e' -i As test_commit offers predictable timestamps, I think you can work around this discrepancy by generating commits n and o before e. (That is not a solution--just a workaround that depends on the current implementation--because the order in which parents of a merge are listed is unspecified.) > +test_expect_success "rebase -p re-creates internal merge" " > + reset_rebase && > + git rebase -p c w && > + test_revision_subjects 'c d n e o w' HEAD~4 HEAD~3 HEAD~2 HEAD^2 HEAD^ HEAD Shouldn't this better be test_cmp_rev c HEAD~4 && test_revision_subjects 'd n e o w' HEAD~3 HEAD~2 HEAD^2 HEAD^ HEAD to ensure that c is not a rewritten commit? > +" > + > +test_expect_success "rebase -p can re-create two branches on onto" " > + reset_rebase && > + git rebase -p --onto c d w && > + test_revision_subjects 'c n e o w' HEAD~3 HEAD~2 HEAD^2 HEAD^ HEAD > +" Same here. Time is fleeting. I have to stop here. -- 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