git/t/t5402-post-merge-hook.sh

57 lines
1.5 KiB
Bash
Raw Normal View History

#!/bin/sh
#
# Copyright (c) 2006 Josh England
#
test_description='Test the post-merge hook.'
. ./test-lib.sh
test_expect_success setup '
echo Data for commit0. >a &&
git update-index --add a &&
tree0=$(git write-tree) &&
commit0=$(echo setup | git commit-tree $tree0) &&
echo Changed data for commit1. >a &&
git update-index a &&
tree1=$(git write-tree) &&
commit1=$(echo modify | git commit-tree $tree1 -p $commit0) &&
git update-ref refs/heads/master $commit0 &&
git clone ./. clone1 &&
GIT_DIR=clone1/.git git update-index --add a &&
git clone ./. clone2 &&
GIT_DIR=clone2/.git git update-index --add a
'
for clone in 1 2; do
cat >clone${clone}/.git/hooks/post-merge <<'EOF'
#!/bin/sh
echo $@ >> $GIT_DIR/post-merge.args
EOF
chmod u+x clone${clone}/.git/hooks/post-merge
done
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 09:50:53 +00:00
test_expect_success 'post-merge does not run for up-to-date ' '
GIT_DIR=clone1/.git git merge $commit0 &&
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 09:50:53 +00:00
! test -f clone1/.git/post-merge.args
'
test_expect_success 'post-merge runs as expected ' '
GIT_DIR=clone1/.git git merge $commit1 &&
test -e clone1/.git/post-merge.args
'
test_expect_success 'post-merge from normal merge receives the right argument ' '
grep 0 clone1/.git/post-merge.args
'
test_expect_success 'post-merge from squash merge runs as expected ' '
GIT_DIR=clone2/.git git merge --squash $commit1 &&
test -e clone2/.git/post-merge.args
'
test_expect_success 'post-merge from squash merge receives the right argument ' '
grep 1 clone2/.git/post-merge.args
'
test_done