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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
