You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

87 lines
2.2 KiB

#!/bin/sh
#
# Copyright (c) 2005 Amos Waterland
#
test_description='git rebase should not destroy author information
This test runs git rebase and checks that the author information is not lost.
'
. ./test-lib.sh
export GIT_AUTHOR_EMAIL=bogus_email_address
test_expect_success \
'prepare repository with topic branches' \
'echo First > A &&
git update-index --add A &&
git-commit -m "Add A." &&
git checkout -b my-topic-branch &&
echo Second > B &&
git update-index --add B &&
git-commit -m "Add B." &&
git checkout -f master &&
echo Third >> A &&
git update-index A &&
git-commit -m "Modify A." &&
git checkout -b side my-topic-branch &&
echo Side >> C &&
git add C &&
git commit -m "Add C" &&
git checkout -b nonlinear my-topic-branch &&
echo Edit >> B &&
git add B &&
git commit -m "Modify B" &&
git merge side &&
git checkout -b upstream-merged-nonlinear &&
git merge master &&
git checkout -f my-topic-branch &&
git tag topic
'
test_expect_success 'rebase against master' '
git rebase master'
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>
17 years ago
test_expect_success \
'the rebase operation should not have destroyed author information' \
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>
17 years ago
'! git log | grep "Author:" | grep "<>"'
test_expect_success 'rebase after merge master' '
git reset --hard topic &&
git merge master &&
git rebase master &&
! git show | grep "^Merge:"
'
test_expect_success 'rebase of history with merges is linearized' '
git checkout nonlinear &&
test 4 = $(git rev-list master.. | wc -l) &&
git rebase master &&
test 3 = $(git rev-list master.. | wc -l)
'
test_expect_success \
'rebase of history with merges after upstream merge is linearized' '
git checkout upstream-merged-nonlinear &&
test 5 = $(git rev-list master.. | wc -l) &&
git rebase master &&
test 3 = $(git rev-list master.. | wc -l)
'
test_expect_success 'rebase a single mode change' '
git checkout master &&
echo 1 > X &&
git add X &&
test_tick &&
git commit -m prepare &&
git checkout -b modechange HEAD^ &&
echo 1 > X &&
git add X &&
chmod a+x A &&
test_tick &&
git commit -m modechange A X &&
GIT_TRACE=1 git rebase master
'
test_done