git/t/t6101-rev-parse-parents.sh

43 строки
1.8 KiB
Bash
Исходник Обычный вид История

#!/bin/sh
#
# Copyright (c) 2005 Johannes Schindelin
#
test_description='Test git rev-parse with different parent options'
. ./test-lib.sh
. ../t6000lib.sh # t6xxx specific functions
date >path0
git update-index --add path0
save_tag tree git write-tree
hide_error save_tag start unique_commit "start" tree
save_tag second unique_commit "second" tree -p start
hide_error save_tag start2 unique_commit "start2" tree
save_tag two_parents unique_commit "next" tree -p second -p start2
save_tag final unique_commit "final" tree -p two_parents
test_expect_success 'start is valid' 'git rev-parse start | grep "^[0-9a-f]\{40\}$"'
test_expect_success 'start^0' "test $(cat .git/refs/tags/start) = $(git rev-parse start^0)"
test_expect_success 'start^1 not valid' "if git rev-parse --verify start^1; then false; else :; fi"
test_expect_success 'second^1 = second^' "test $(git rev-parse second^1) = $(git rev-parse second^)"
test_expect_success 'final^1^1^1' "test $(git rev-parse start) = $(git rev-parse final^1^1^1)"
test_expect_success 'final^1^1^1 = final^^^' "test $(git rev-parse final^1^1^1) = $(git rev-parse final^^^)"
test_expect_success 'final^1^2' "test $(git rev-parse start2) = $(git rev-parse final^1^2)"
test_expect_success 'final^1^2 != final^1^1' "test $(git rev-parse final^1^2) != $(git rev-parse final^1^1)"
test_expect_success 'final^1^3 not valid' "if git rev-parse --verify final^1^3; then false; else :; fi"
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 12:50:53 +03:00
test_expect_success '--verify start2^1' '! git rev-parse --verify start2^1'
test_expect_success '--verify start2^0' 'git rev-parse --verify start2^0'
test_expect_success 'repack for next test' 'git repack -a -d'
test_expect_success 'short SHA-1 works' '
start=`git rev-parse --verify start` &&
echo $start &&
abbrv=`echo $start | sed s/.\$//` &&
echo $abbrv &&
abbrv=`git rev-parse --verify $abbrv` &&
echo $abbrv &&
test $start = $abbrv'
test_done