Martin von Zweigbergk <martinvonz@xxxxxxxxx> writes: > --- > +#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 I do not quite follow this TODO. While I think it would be nice to update "rebase" so that all variants consider replaying the commits in the same order, in this history you have: +# a---b-----------c +# \ \ +# d-------e \ +# \ \ \ +# n---o---w---v +# \ +# z as long as o comes after n and e is shown before n or after o, which all three expected results satisify, it is in --topo-order, isn't it? The same comment applies to the other TODO that talks about eno/noe differences. > +test_expect_success "rebase -p re-creates merge from side branch" " > + reset_rebase && > + git rebase -p z w && > + test_cmp_rev z HEAD^ && > + test_cmp_rev w^2 HEAD^2 > +" Hmm, turning the left one to the right one? +# d-------e d-------e +# \ \ \ \ +# n---o---w ===> n---o \ +# \ \ \ +# z z---W If w were a merge of o into e (i.e. w^1 were e not o), what should happen? Would we get the same topology? In other words, when asked to replay w on top of z, how would we decide which parent to keep (in this case, e is kept)? > +test_expect_success "rebase -p can re-create two branches on onto" " > + reset_rebase && > + git rebase -p --onto c d w && > + test_cmp_rev c HEAD~3 && > + test_cmp_rev c HEAD^2^ && > + test_revision_subjects 'n e o w' HEAD~2 HEAD^2 HEAD^ HEAD > +" Nice (so are all the rest). -- 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