1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-06-01 22:56:10 +02:00
git/t/t3421-rebase-topology-linea...

381 lines
8.6 KiB
Bash
Raw Normal View History

#!/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_have_prereq !REBASE_P || test_run_rebase success -p
test_expect_success 'setup branches and remote tracking' '
git tag -l >tags &&
for tag in $(cat tags)
do
git branch branch-$tag $tag || return 1
done &&
git remote add origin "file://$PWD" &&
git fetch origin
'
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_have_prereq !REBASE_P || 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 &&
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 --fork-point
test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase failure -p
test_run_rebase () {
result=$1
shift
test_expect_$result "rebase $* -f rewrites even if remote upstream is an ancestor" "
reset_rebase &&
git rebase $* -f branch-b branch-e &&
test_cmp_rev ! branch-e origin/branch-e &&
test_cmp_rev branch-b HEAD~2 &&
test_linear_range 'd e' branch-b..
"
}
test_run_rebase success ''
test_run_rebase success --fork-point
test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase success -p
test_run_rebase () {
result=$1
shift
test_expect_$result "rebase $* fast-forwards from ancestor of upstream" "
reset_rebase &&
git rebase $* e b &&
test_cmp_rev e HEAD
"
}
test_run_rebase success ''
test_run_rebase success --fork-point
test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase success -p
# f
# /
# a---b---c---g---h
# \
# d---gp--i
#
# gp = cherry-picked g
# h = reverted g
#
# Reverted patches are there for tests to be able to check if a commit
# that introduced the same change as another commit is
# dropped. Without reverted commits, we could get false positives
# because applying the patch succeeds, but simply results in no
# changes.
test_expect_success 'setup of linear history for range selection tests' '
git checkout c &&
test_commit g &&
revert h g &&
git checkout d &&
cherry_pick gp g &&
test_commit i &&
git checkout b &&
test_commit f
'
test_run_rebase () {
result=$1
shift
test_expect_$result "rebase $* drops patches in upstream" "
reset_rebase &&
git rebase $* h i &&
test_cmp_rev h HEAD~2 &&
test_linear_range 'd i' h..
"
}
test_run_rebase success ''
rebase: implement --merge via the interactive machinery As part of an ongoing effort to make rebase have more uniform behavior, modify the merge backend to behave like the interactive one, by re-implementing it on top of the latter. Interactive rebases are implemented in terms of cherry-pick rather than the merge-recursive builtin, but cherry-pick also calls into the recursive merge machinery by default and can accept special merge strategies and/or special strategy options. As such, there really is not any need for having both git-rebase--merge and git-rebase--interactive anymore. Delete git-rebase--merge.sh and instead implement it in builtin/rebase.c. This results in a few deliberate but small user-visible changes: * The progress output is modified (see t3406 and t3420 for examples) * A few known test failures are now fixed (see t3421) * bash-prompt during a rebase --merge is now REBASE-i instead of REBASE-m. Reason: The prompt is a reflection of the backend in use; this allows users to report an issue to the git mailing list with the appropriate backend information, and allows advanced users to know where to search for relevant control files. (see t9903) testcase modification notes: t3406: --interactive and --merge had slightly different progress output while running; adjust a test to match the new expectation t3420: these test precise output while running, but rebase--am, rebase--merge, and rebase--interactive all were built on very different commands (am, merge-recursive, cherry-pick), so the tests expected different output for each type. Now we expect --merge and --interactive to have the same output. t3421: --interactive fixes some bugs in --merge! Wahoo! t9903: --merge uses the interactive backend so the prompt expected is now REBASE-i. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-11 17:11:39 +01:00
test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase success -p
test_run_rebase () {
result=$1
shift
test_expect_$result "rebase $* can drop last patch if in upstream" "
reset_rebase &&
git rebase $* h gp &&
test_cmp_rev h HEAD^ &&
test_linear_range 'd' h..
"
}
test_run_rebase success ''
rebase: implement --merge via the interactive machinery As part of an ongoing effort to make rebase have more uniform behavior, modify the merge backend to behave like the interactive one, by re-implementing it on top of the latter. Interactive rebases are implemented in terms of cherry-pick rather than the merge-recursive builtin, but cherry-pick also calls into the recursive merge machinery by default and can accept special merge strategies and/or special strategy options. As such, there really is not any need for having both git-rebase--merge and git-rebase--interactive anymore. Delete git-rebase--merge.sh and instead implement it in builtin/rebase.c. This results in a few deliberate but small user-visible changes: * The progress output is modified (see t3406 and t3420 for examples) * A few known test failures are now fixed (see t3421) * bash-prompt during a rebase --merge is now REBASE-i instead of REBASE-m. Reason: The prompt is a reflection of the backend in use; this allows users to report an issue to the git mailing list with the appropriate backend information, and allows advanced users to know where to search for relevant control files. (see t9903) testcase modification notes: t3406: --interactive and --merge had slightly different progress output while running; adjust a test to match the new expectation t3420: these test precise output while running, but rebase--am, rebase--merge, and rebase--interactive all were built on very different commands (am, merge-recursive, cherry-pick), so the tests expected different output for each type. Now we expect --merge and --interactive to have the same output. t3421: --interactive fixes some bugs in --merge! Wahoo! t9903: --merge uses the interactive backend so the prompt expected is now REBASE-i. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-11 17:11:39 +01:00
test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase success -p
test_run_rebase () {
result=$1
shift
test_expect_$result "rebase $* --onto drops patches in upstream" "
reset_rebase &&
git rebase $* --onto f h i &&
test_cmp_rev f HEAD~2 &&
test_linear_range 'd i' f..
"
}
test_run_rebase success ''
rebase: implement --merge via the interactive machinery As part of an ongoing effort to make rebase have more uniform behavior, modify the merge backend to behave like the interactive one, by re-implementing it on top of the latter. Interactive rebases are implemented in terms of cherry-pick rather than the merge-recursive builtin, but cherry-pick also calls into the recursive merge machinery by default and can accept special merge strategies and/or special strategy options. As such, there really is not any need for having both git-rebase--merge and git-rebase--interactive anymore. Delete git-rebase--merge.sh and instead implement it in builtin/rebase.c. This results in a few deliberate but small user-visible changes: * The progress output is modified (see t3406 and t3420 for examples) * A few known test failures are now fixed (see t3421) * bash-prompt during a rebase --merge is now REBASE-i instead of REBASE-m. Reason: The prompt is a reflection of the backend in use; this allows users to report an issue to the git mailing list with the appropriate backend information, and allows advanced users to know where to search for relevant control files. (see t9903) testcase modification notes: t3406: --interactive and --merge had slightly different progress output while running; adjust a test to match the new expectation t3420: these test precise output while running, but rebase--am, rebase--merge, and rebase--interactive all were built on very different commands (am, merge-recursive, cherry-pick), so the tests expected different output for each type. Now we expect --merge and --interactive to have the same output. t3421: --interactive fixes some bugs in --merge! Wahoo! t9903: --merge uses the interactive backend so the prompt expected is now REBASE-i. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-11 17:11:39 +01:00
test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase success -p
test_run_rebase () {
result=$1
shift
test_expect_$result "rebase $* --onto does not drop patches in onto" "
reset_rebase &&
git rebase $* --onto h f i &&
test_cmp_rev h HEAD~3 &&
test_linear_range 'd gp i' h..
"
}
test_run_rebase success ''
test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase success -p
# a---b---c---j!
# \
# d---k!--l
#
# ! = empty
test_expect_success 'setup of linear history for empty commit tests' '
git checkout c &&
make_empty j &&
git checkout d &&
make_empty k &&
test_commit l
'
test_run_rebase () {
result=$1
shift
test_expect_$result "rebase $* drops empty commit" "
reset_rebase &&
git rebase $* c l &&
test_cmp_rev c HEAD~2 &&
test_linear_range 'd l' c..
"
}
test_run_rebase success ''
test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase success -p
test_run_rebase () {
result=$1
shift
test_expect_$result "rebase $* --keep-empty" "
reset_rebase &&
git rebase $* --keep-empty c l &&
test_cmp_rev c HEAD~3 &&
test_linear_range 'd k l' c..
"
}
test_run_rebase success ''
test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase failure -p
test_run_rebase () {
result=$1
shift
test_expect_$result "rebase $* --keep-empty keeps empty even if already in upstream" "
reset_rebase &&
git rebase $* --keep-empty j l &&
test_cmp_rev j HEAD~3 &&
test_linear_range 'd k l' j..
"
}
test_run_rebase success ''
test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase failure -p
test_run_rebase success --rebase-merges
# m
# /
# a---b---c---g
#
# x---y---bp
#
# bp = cherry-picked b
# m = reverted b
#
# Reverted patches are there for tests to be able to check if a commit
# that introduced the same change as another commit is
# dropped. Without reverted commits, we could get false positives
# because applying the patch succeeds, but simply results in no
# changes.
test_expect_success 'setup of linear history for test involving root' '
git checkout b &&
revert m b &&
git checkout --orphan disjoint &&
git rm -rf . &&
test_commit x &&
test_commit y &&
cherry_pick bp b
'
test_run_rebase () {
result=$1
shift
test_expect_$result "rebase $* --onto --root" "
reset_rebase &&
git rebase $* --onto c --root y &&
test_cmp_rev c HEAD~2 &&
test_linear_range 'x y' c..
"
}
test_run_rebase success ''
test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase success -p
test_run_rebase () {
result=$1
shift
test_expect_$result "rebase $* without --onto --root with disjoint history" "
reset_rebase &&
git rebase $* c y &&
test_cmp_rev c HEAD~2 &&
test_linear_range 'x y' c..
"
}
test_run_rebase success ''
test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase failure -p
test_run_rebase () {
result=$1
shift
test_expect_$result "rebase $* --onto --root drops patch in onto" "
reset_rebase &&
git rebase $* --onto m --root bp &&
test_cmp_rev m HEAD~2 &&
test_linear_range 'x y' m..
"
}
test_run_rebase success ''
rebase: implement --merge via the interactive machinery As part of an ongoing effort to make rebase have more uniform behavior, modify the merge backend to behave like the interactive one, by re-implementing it on top of the latter. Interactive rebases are implemented in terms of cherry-pick rather than the merge-recursive builtin, but cherry-pick also calls into the recursive merge machinery by default and can accept special merge strategies and/or special strategy options. As such, there really is not any need for having both git-rebase--merge and git-rebase--interactive anymore. Delete git-rebase--merge.sh and instead implement it in builtin/rebase.c. This results in a few deliberate but small user-visible changes: * The progress output is modified (see t3406 and t3420 for examples) * A few known test failures are now fixed (see t3421) * bash-prompt during a rebase --merge is now REBASE-i instead of REBASE-m. Reason: The prompt is a reflection of the backend in use; this allows users to report an issue to the git mailing list with the appropriate backend information, and allows advanced users to know where to search for relevant control files. (see t9903) testcase modification notes: t3406: --interactive and --merge had slightly different progress output while running; adjust a test to match the new expectation t3420: these test precise output while running, but rebase--am, rebase--merge, and rebase--interactive all were built on very different commands (am, merge-recursive, cherry-pick), so the tests expected different output for each type. Now we expect --merge and --interactive to have the same output. t3421: --interactive fixes some bugs in --merge! Wahoo! t9903: --merge uses the interactive backend so the prompt expected is now REBASE-i. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-11 17:11:39 +01:00
test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase success -p
test_run_rebase () {
result=$1
shift
test_expect_$result "rebase $* --onto --root with merge-base does not go to root" "
reset_rebase &&
git rebase $* --onto m --root g &&
test_cmp_rev m HEAD~2 &&
test_linear_range 'c g' m..
"
}
test_run_rebase success ''
test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase failure -p
test_run_rebase () {
result=$1
shift
test_expect_$result "rebase $* without --onto --root with disjoint history drops patch in onto" "
reset_rebase &&
git rebase $* m bp &&
test_cmp_rev m HEAD~2 &&
test_linear_range 'x y' m..
"
}
test_run_rebase success ''
rebase: implement --merge via the interactive machinery As part of an ongoing effort to make rebase have more uniform behavior, modify the merge backend to behave like the interactive one, by re-implementing it on top of the latter. Interactive rebases are implemented in terms of cherry-pick rather than the merge-recursive builtin, but cherry-pick also calls into the recursive merge machinery by default and can accept special merge strategies and/or special strategy options. As such, there really is not any need for having both git-rebase--merge and git-rebase--interactive anymore. Delete git-rebase--merge.sh and instead implement it in builtin/rebase.c. This results in a few deliberate but small user-visible changes: * The progress output is modified (see t3406 and t3420 for examples) * A few known test failures are now fixed (see t3421) * bash-prompt during a rebase --merge is now REBASE-i instead of REBASE-m. Reason: The prompt is a reflection of the backend in use; this allows users to report an issue to the git mailing list with the appropriate backend information, and allows advanced users to know where to search for relevant control files. (see t9903) testcase modification notes: t3406: --interactive and --merge had slightly different progress output while running; adjust a test to match the new expectation t3420: these test precise output while running, but rebase--am, rebase--merge, and rebase--interactive all were built on very different commands (am, merge-recursive, cherry-pick), so the tests expected different output for each type. Now we expect --merge and --interactive to have the same output. t3421: --interactive fixes some bugs in --merge! Wahoo! t9903: --merge uses the interactive backend so the prompt expected is now REBASE-i. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-11 17:11:39 +01:00
test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase failure -p
test_run_rebase () {
result=$1
shift
test_expect_$result "rebase $* --root on linear history is a no-op" "
reset_rebase &&
git rebase $* --root c &&
test_cmp_rev c HEAD
"
}
test_run_rebase success ''
test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase failure -p
test_run_rebase () {
result=$1
shift
test_expect_$result "rebase $* -f --root on linear history causes re-write" "
reset_rebase &&
git rebase $* -f --root c &&
test_cmp_rev ! a HEAD~2 &&
test_linear_range 'a b c' HEAD
"
}
test_run_rebase success ''
test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase success -p
test_done