Martin von Zweigbergk <[email protected]> writes:
> Helped-by: Johannes Sixt <[email protected]>
> ---
> t/lib-rebase.sh | 15 ++++++++
> t/t3421-rebase-topology-linear.sh | 78
> +++++++++++++++++++++++++++++++++++++++
> 2 files changed, 93 insertions(+)
> create mode 100755 t/t3421-rebase-topology-linear.sh
>
> diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
> index 6ccf797..62b3887 100644
> --- a/t/lib-rebase.sh
> +++ b/t/lib-rebase.sh
> @@ -65,3 +65,18 @@ EOF
> test_set_editor "$(pwd)/fake-editor.sh"
> chmod a+x fake-editor.sh
> }
> +
> +# checks that the revisions in "$2" represent a linear range with the
> +# subjects in "$1"
> +test_linear_range () {
> + ! { git log --format=%p "$2" | sane_grep " " ;} &&
An interesting way to spell:
test $(git rev-list --merges "$2" | wc -l) = 0
I think I am fine with either, though.
> + expected=$1
> + set -- $(git log --reverse --format=%s "$2")
> + test "$expected" = "$*"
OK.
> +}
> +
> +reset_rebase () {
> + git rebase --abort # may fail; ignore exit code
test_might_fail to catch unusual exit codes?
> + git reset --hard &&
> + git clean -f
> +}
> diff --git a/t/t3421-rebase-topology-linear.sh
> b/t/t3421-rebase-topology-linear.sh
> new file mode 100755
> index 0000000..c4b32db
> --- /dev/null
> +++ b/t/t3421-rebase-topology-linear.sh
> @@ -0,0 +1,78 @@
> +#!/bin/sh
> +
> +test_description='basic rebase topology tests'
> +. ./test-lib.sh
> +. "$TEST_DIRECTORY"/lib-rebase.sh
> +
> +# a---b---c
> +# \
> +# d---e
> +test_expect_success 'setup' '
> + test_commit a &&
> + test_commit b &&
> + test_commit c &&
> + git checkout b &&
> + test_commit d &&
> + test_commit e
> +'
> +
> +test_run_rebase () {
> + result=$1
> + shift
> + test_expect_$result "simple rebase $*" "
> + reset_rebase &&
> + git rebase $* c e &&
> + test_cmp_rev c HEAD~2 &&
> + test_linear_range 'd e' c..
> + "
> +}
> +test_run_rebase success ''
> +test_run_rebase success -m
> +test_run_rebase success -i
> +test_run_rebase success -p
> +
> +test_run_rebase () {
> + result=$1
> + shift
> + test_expect_$result "rebase $* is no-op if upstream is an ancestor" "
> + reset_rebase &&
> + git rebase $* b e &&
> + test_cmp_rev e HEAD
> + "
> +}
> +test_run_rebase success ''
> +test_run_rebase success -m
> +test_run_rebase success -i
> +test_run_rebase success -p
> +
> +test_run_rebase () {
> + result=$1
> + shift
> + test_expect_$result "rebase $* -f rewrites even if upstream is an
> ancestor" "
> + reset_rebase &&
> + git rebase $* -f b e &&
Asking to rebase the history leading to e from b on top of the merge
base (which happens to be b) may be no-op or force-create a new
history that is parallel. OK.
> + ! test_cmp_rev e HEAD &&
> + test_cmp_rev b HEAD~2 &&
> + test_linear_range 'd e' b..
> + "
> +}
> +test_run_rebase success ''
> +test_run_rebase success -m
> +test_run_rebase success -i
> +test_run_rebase failure -p
> +
> +test_run_rebase () {
> + result=$1
> + shift
> + test_expect_$result "rebase $* fast-forwards if an ancestor of
> upstream" "
The description is a non-sentence, and while I can tell what it
wants to say, I do not have a good suggestion for rephrasing this.
This is asking to rebase the history leading to b on top of e, but e
already includes everything in b, so it just turns into a no-op of
not moving from e. So it is not even a fast-forward.
> + reset_rebase &&
> + git rebase $* e b &&
> + test_cmp_rev e HEAD
> + "
> +}
> +test_run_rebase success ''
> +test_run_rebase success -m
> +test_run_rebase success -i
> +test_run_rebase success -p
> +
> +test_done
--
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
