Re: [PATCH v5 5/7] add tests for rebasing merged history

[Junio C Hamano <gitster@pobox.com>]

Martin von Zweigbergk <martinvonz@gmail.com> 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).