1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-14 21:23:03 +01:00
git/t/t3403-rebase-skip.sh

72 lines
1.7 KiB
Bash
Raw Normal View History

#!/bin/sh
#
# Copyright (c) 2006 Eric Wong
#
test_description='git rebase --merge --skip tests'
. ./test-lib.sh
# we assume the default git-am -3 --skip strategy is tested independently
# and always works :)
test_expect_success setup '
echo hello > hello &&
git add hello &&
git commit -m "hello" &&
git branch skip-reference &&
echo world >> hello &&
git commit -a -m "hello world" &&
echo goodbye >> hello &&
git commit -a -m "goodbye" &&
git checkout -f skip-reference &&
echo moo > hello &&
git commit -a -m "we should skip this" &&
echo moo > cow &&
git add cow &&
git commit -m "this should not be skipped" &&
git branch pre-rebase skip-reference &&
git branch skip-merge skip-reference
'
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 10:50:53 +01:00
test_expect_success 'rebase with git am -3 (default)' '
! git rebase master
'
test_expect_success 'rebase --skip with am -3' '
git rebase --skip
'
test_expect_success 'rebase moves back to skip-reference' '
test refs/heads/skip-reference = $(git symbolic-ref HEAD) &&
git branch post-rebase &&
git reset --hard pre-rebase &&
! git rebase master &&
echo "hello" > hello &&
git add hello &&
git rebase --continue &&
test refs/heads/skip-reference = $(git symbolic-ref HEAD) &&
git reset --hard post-rebase
'
test_expect_success 'checkout skip-merge' 'git checkout -f skip-merge'
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 10:50:53 +01:00
test_expect_success 'rebase with --merge' '! git rebase --merge master'
test_expect_success 'rebase --skip with --merge' '
git rebase --skip
'
test_expect_success 'merge and reference trees equal' \
'test -z "`git diff-tree skip-merge skip-reference`"'
test_expect_success 'moved back to branch correctly' '
test refs/heads/skip-merge = $(git symbolic-ref HEAD)
'
test_debug 'gitk --all & sleep 1'
test_done