git/t/t6030-bisect-porcelain.sh

966 lines
30 KiB
Bash
Raw Normal View History

#!/bin/sh
#
# Copyright (c) 2007 Christian Couder
#
test_description='Tests git bisect functionality'
exec </dev/null
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
tests: mark tests relying on the current default for `init.defaultBranch` In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-18 23:44:19 +00:00
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
. ./test-lib.sh
add_line_into_file()
{
_line=$1
_file=$2
if [ -f "$_file" ]; then
echo "$_line" >> $_file || return $?
MSG="Add <$_line> into <$_file>."
else
echo "$_line" > $_file || return $?
git add $_file || return $?
MSG="Create file <$_file> with <$_line> inside."
fi
test_tick
git commit --quiet -m "$MSG" $_file
}
HASH1=
HASH2=
HASH3=
HASH4=
test_expect_success 'set up basic repo with 1 file (hello) and 4 commits' '
add_line_into_file "1: Hello World" hello &&
HASH1=$(git rev-parse --verify HEAD) &&
add_line_into_file "2: A new day for git" hello &&
HASH2=$(git rev-parse --verify HEAD) &&
add_line_into_file "3: Another new day for git" hello &&
HASH3=$(git rev-parse --verify HEAD) &&
add_line_into_file "4: Ciao for now" hello &&
HASH4=$(git rev-parse --verify HEAD)
'
test_expect_success 'bisect starts with only one bad' '
git bisect reset &&
git bisect start &&
git bisect bad $HASH4 &&
git bisect next
'
test_expect_success 'bisect does not start with only one good' '
git bisect reset &&
git bisect start &&
git bisect good $HASH1 &&
test_must_fail git bisect next
'
test_expect_success 'bisect start with one bad and good' '
git bisect reset &&
git bisect start &&
git bisect good $HASH1 &&
git bisect bad $HASH4 &&
git bisect next
'
test_expect_success 'bisect fails if given any junk instead of revs' '
git bisect reset &&
test_must_fail git bisect start foo $HASH1 -- &&
test_must_fail git bisect start $HASH4 $HASH1 bar -- &&
test -z "$(git for-each-ref "refs/bisect/*")" &&
test -z "$(ls .git/BISECT_* 2>/dev/null)" &&
git bisect start &&
test_must_fail git bisect good foo $HASH1 &&
test_must_fail git bisect good $HASH1 bar &&
test_must_fail git bisect bad frotz &&
test_must_fail git bisect bad $HASH3 $HASH4 &&
test_must_fail git bisect skip bar $HASH3 &&
test_must_fail git bisect skip $HASH1 foo &&
test -z "$(git for-each-ref "refs/bisect/*")" &&
git bisect good $HASH1 &&
git bisect bad $HASH4
'
test_expect_success 'bisect start without -- takes unknown arg as pathspec' '
git bisect reset &&
git bisect start foo bar &&
grep foo ".git/BISECT_NAMES" &&
grep bar ".git/BISECT_NAMES"
'
test_expect_success 'bisect reset: back in the main branch' '
git bisect reset &&
echo "* main" > branch.expect &&
git branch > branch.output &&
cmp branch.expect branch.output
'
test_expect_success 'bisect reset: back in another branch' '
git checkout -b other &&
git bisect start &&
git bisect good $HASH1 &&
git bisect bad $HASH3 &&
git bisect reset &&
echo " main" > branch.expect &&
echo "* other" >> branch.expect &&
git branch > branch.output &&
cmp branch.expect branch.output
'
test_expect_success 'bisect reset when not bisecting' '
git bisect reset &&
git branch > branch.output &&
cmp branch.expect branch.output
'
test_expect_success 'bisect reset removes packed refs' '
git bisect reset &&
git bisect start &&
git bisect good $HASH1 &&
git bisect bad $HASH3 &&
git pack-refs --all --prune &&
git bisect next &&
git bisect reset &&
test -z "$(git for-each-ref "refs/bisect/*")" &&
test -z "$(git for-each-ref "refs/heads/bisect")"
'
test_expect_success 'bisect reset removes bisect state after --no-checkout' '
git bisect reset &&
git bisect start --no-checkout &&
git bisect good $HASH1 &&
git bisect bad $HASH3 &&
git bisect next &&
git bisect reset &&
test -z "$(git for-each-ref "refs/bisect/*")" &&
test -z "$(git for-each-ref "refs/heads/bisect")" &&
test -z "$(git for-each-ref "BISECT_HEAD")"
'
test_expect_success 'bisect start: back in good branch' '
git branch > branch.output &&
grep "* other" branch.output > /dev/null &&
git bisect start $HASH4 $HASH1 -- &&
git bisect good &&
git bisect start $HASH4 $HASH1 -- &&
git bisect bad &&
git bisect reset &&
git branch > branch.output &&
grep "* other" branch.output > /dev/null
'
test_expect_success 'bisect start: no ".git/BISECT_START" created if junk rev' '
git bisect reset &&
test_must_fail git bisect start $HASH4 foo -- &&
git branch > branch.output &&
grep "* other" branch.output > /dev/null &&
test_path_is_missing .git/BISECT_START
'
test_expect_success 'bisect start: existing ".git/BISECT_START" not modified if junk rev' '
git bisect start $HASH4 $HASH1 -- &&
git bisect good &&
cp .git/BISECT_START saved &&
test_must_fail git bisect start $HASH4 foo -- &&
git branch > branch.output &&
test_i18ngrep "* (no branch, bisect started on other)" branch.output > /dev/null &&
test_cmp saved .git/BISECT_START
'
test_expect_success 'bisect start: no ".git/BISECT_START" if mistaken rev' '
git bisect start $HASH4 $HASH1 -- &&
git bisect good &&
test_must_fail git bisect start $HASH1 $HASH4 -- &&
git branch > branch.output &&
grep "* other" branch.output > /dev/null &&
test_path_is_missing .git/BISECT_START
'
test_expect_success 'bisect start: no ".git/BISECT_START" if checkout error' '
echo "temp stuff" > hello &&
test_must_fail git bisect start $HASH4 $HASH1 -- &&
git branch &&
git branch > branch.output &&
grep "* other" branch.output > /dev/null &&
test_path_is_missing .git/BISECT_START &&
test -z "$(git for-each-ref "refs/bisect/*")" &&
git checkout HEAD hello
'
# $HASH1 is good, $HASH4 is bad, we skip $HASH3
# but $HASH2 is bad,
# so we should find $HASH2 as the first bad commit
test_expect_success 'bisect skip: successful result' '
test_when_finished git bisect reset &&
git bisect reset &&
git bisect start $HASH4 $HASH1 &&
git bisect skip &&
git bisect bad > my_bisect_log.txt &&
grep "$HASH2 is the first bad commit" my_bisect_log.txt
'
# $HASH1 is good, $HASH4 is bad, we skip $HASH3 and $HASH2
# so we should not be able to tell the first bad commit
# among $HASH2, $HASH3 and $HASH4
test_expect_success 'bisect skip: cannot tell between 3 commits' '
test_when_finished git bisect reset &&
git bisect start $HASH4 $HASH1 &&
git bisect skip &&
test_expect_code 2 git bisect skip >my_bisect_log.txt &&
grep "first bad commit could be any of" my_bisect_log.txt &&
! grep $HASH1 my_bisect_log.txt &&
grep $HASH2 my_bisect_log.txt &&
grep $HASH3 my_bisect_log.txt &&
grep $HASH4 my_bisect_log.txt
'
# $HASH1 is good, $HASH4 is bad, we skip $HASH3
# but $HASH2 is good,
# so we should not be able to tell the first bad commit
# among $HASH3 and $HASH4
test_expect_success 'bisect skip: cannot tell between 2 commits' '
test_when_finished git bisect reset &&
git bisect start $HASH4 $HASH1 &&
git bisect skip &&
test_expect_code 2 git bisect good >my_bisect_log.txt &&
grep "first bad commit could be any of" my_bisect_log.txt &&
! grep $HASH1 my_bisect_log.txt &&
! grep $HASH2 my_bisect_log.txt &&
grep $HASH3 my_bisect_log.txt &&
grep $HASH4 my_bisect_log.txt
'
# $HASH1 is good, $HASH4 is both skipped and bad, we skip $HASH3
# and $HASH2 is good,
# so we should not be able to tell the first bad commit
# among $HASH3 and $HASH4
test_expect_success 'bisect skip: with commit both bad and skipped' '
test_when_finished git bisect reset &&
git bisect start &&
git bisect skip &&
git bisect bad &&
git bisect good $HASH1 &&
git bisect skip &&
test_expect_code 2 git bisect good >my_bisect_log.txt &&
grep "first bad commit could be any of" my_bisect_log.txt &&
! grep $HASH1 my_bisect_log.txt &&
! grep $HASH2 my_bisect_log.txt &&
grep $HASH3 my_bisect_log.txt &&
grep $HASH4 my_bisect_log.txt
'
# We want to automatically find the commit that
# added "Another" into hello.
test_expect_success '"git bisect run" simple case' '
write_script test_script.sh <<-\EOF &&
! grep Another hello >/dev/null
EOF
git bisect start &&
git bisect good $HASH1 &&
git bisect bad $HASH4 &&
git bisect run ./test_script.sh >my_bisect_log.txt &&
grep "$HASH3 is the first bad commit" my_bisect_log.txt &&
git bisect reset
'
# We want to automatically find the commit that
# added "Ciao" into hello.
test_expect_success '"git bisect run" with more complex "git bisect start"' '
write_script test_script.sh <<-\EOF &&
! grep Ciao hello >/dev/null
EOF
git bisect start $HASH4 $HASH1 &&
git bisect run ./test_script.sh >my_bisect_log.txt &&
grep "$HASH4 is the first bad commit" my_bisect_log.txt &&
git bisect reset
'
# $HASH1 is good, $HASH5 is bad, we skip $HASH3
# but $HASH4 is good,
# so we should find $HASH5 as the first bad commit
HASH5=
test_expect_success 'bisect skip: add line and then a new test' '
add_line_into_file "5: Another new line." hello &&
HASH5=$(git rev-parse --verify HEAD) &&
git bisect start $HASH5 $HASH1 &&
git bisect skip &&
git bisect good > my_bisect_log.txt &&
grep "$HASH5 is the first bad commit" my_bisect_log.txt &&
git bisect log > log_to_replay.txt &&
git bisect reset
'
test_expect_success 'bisect skip and bisect replay' '
git bisect replay log_to_replay.txt > my_bisect_log.txt &&
grep "$HASH5 is the first bad commit" my_bisect_log.txt &&
git bisect reset
'
HASH6=
test_expect_success 'bisect run & skip: cannot tell between 2' '
add_line_into_file "6: Yet a line." hello &&
HASH6=$(git rev-parse --verify HEAD) &&
write_script test_script.sh <<-\EOF &&
sed -ne \$p hello | grep Ciao >/dev/null && exit 125
! grep line hello >/dev/null
EOF
git bisect start $HASH6 $HASH1 &&
test_expect_code 2 git bisect run ./test_script.sh >my_bisect_log.txt &&
grep "first bad commit could be any of" my_bisect_log.txt &&
! grep $HASH3 my_bisect_log.txt &&
! grep $HASH6 my_bisect_log.txt &&
grep $HASH4 my_bisect_log.txt &&
grep $HASH5 my_bisect_log.txt
'
HASH7=
test_expect_success 'bisect run & skip: find first bad' '
git bisect reset &&
add_line_into_file "7: Should be the last line." hello &&
HASH7=$(git rev-parse --verify HEAD) &&
write_script test_script.sh <<-\EOF &&
sed -ne \$p hello | grep Ciao >/dev/null && exit 125
sed -ne \$p hello | grep day >/dev/null && exit 125
! grep Yet hello >/dev/null
EOF
git bisect start $HASH7 $HASH1 &&
git bisect run ./test_script.sh >my_bisect_log.txt &&
grep "$HASH6 is the first bad commit" my_bisect_log.txt
'
test_expect_success 'bisect skip only one range' '
git bisect reset &&
git bisect start $HASH7 $HASH1 &&
git bisect skip $HASH1..$HASH5 &&
test "$HASH6" = "$(git rev-parse --verify HEAD)" &&
test_must_fail git bisect bad > my_bisect_log.txt &&
grep "first bad commit could be any of" my_bisect_log.txt
'
test_expect_success 'bisect skip many ranges' '
git bisect start $HASH7 $HASH1 &&
test "$HASH4" = "$(git rev-parse --verify HEAD)" &&
git bisect skip $HASH2 $HASH2.. ..$HASH5 &&
test "$HASH6" = "$(git rev-parse --verify HEAD)" &&
test_must_fail git bisect bad > my_bisect_log.txt &&
grep "first bad commit could be any of" my_bisect_log.txt
'
test_expect_success 'bisect starting with a detached HEAD' '
git bisect reset &&
git checkout main^ &&
HEAD=$(git rev-parse --verify HEAD) &&
git bisect start &&
test $HEAD = $(cat .git/BISECT_START) &&
git bisect reset &&
test $HEAD = $(git rev-parse --verify HEAD)
'
test_expect_success 'bisect errors out if bad and good are mistaken' '
git bisect reset &&
test_must_fail git bisect start $HASH2 $HASH4 2> rev_list_error &&
test_i18ngrep "mistook good and bad" rev_list_error &&
git bisect reset
'
test_expect_success 'bisect does not create a "bisect" branch' '
git bisect reset &&
git bisect start $HASH7 $HASH1 &&
git branch bisect &&
rev_hash4=$(git rev-parse --verify HEAD) &&
test "$rev_hash4" = "$HASH4" &&
git branch -D bisect &&
git bisect good &&
git branch bisect &&
rev_hash6=$(git rev-parse --verify HEAD) &&
test "$rev_hash6" = "$HASH6" &&
git bisect good > my_bisect_log.txt &&
grep "$HASH7 is the first bad commit" my_bisect_log.txt &&
git bisect reset &&
rev_hash6=$(git rev-parse --verify bisect) &&
test "$rev_hash6" = "$HASH6" &&
git branch -D bisect
'
bisect: test merge base if good rev is not an ancestor of bad rev Before this patch, "git bisect", when it was given some good revs that are not ancestor of the bad rev, didn't check if the merge bases were good. "git bisect" just supposed that the user knew what he was doing, and that, when he said the revs were good, he knew that it meant that all the revs in the history leading to the good revs were also considered good. But in pratice, the user may not know that a good rev is not an ancestor of the bad rev, or he may not know/remember that all revs leading to the good rev will be considered good. So he may give a good rev that is a sibling, instead of an ancestor, of the bad rev, when in fact there can be one rev becoming good in the branch of the good rev (because the bug was already fixed there, for example) instead of one rev becoming bad in the branch of the bad rev. For example, if there is the following history: A--B--C--D \ E--F and we launch "git bisect start D F" then only C and D would have been considered as possible first bad commit before this patch. This could invite user errors; F could be the commit that fixes the bug that exists everywhere else. The purpose of this patch is to detect when "git bisect" is passed some good revs that are not ancestors of the bad rev, and then to first ask the user to test the merge bases between the good and bad revs. If the merge bases are good then all is fine, we can continue bisecting. Otherwise, if one merge base is bad, it means that the assumption that all revs leading to the good one are good too is wrong and we error out. In the case where one merge base is skipped we issue a warning and then continue bisecting anyway. These checks will also catch the case where good and bad have been mistaken. This means that we can remove the check that was done latter on the output of "git rev-list --bisect-vars". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-22 03:52:22 +00:00
# This creates a "side" branch to test "siblings" cases.
#
# H1-H2-H3-H4-H5-H6-H7 <--other
# \
# S5-S6-S7 <--side
#
test_expect_success 'side branch creation' '
git bisect reset &&
git checkout -b side $HASH4 &&
add_line_into_file "5(side): first line on a side branch" hello2 &&
SIDE_HASH5=$(git rev-parse --verify HEAD) &&
add_line_into_file "6(side): second line on a side branch" hello2 &&
SIDE_HASH6=$(git rev-parse --verify HEAD) &&
add_line_into_file "7(side): third line on a side branch" hello2 &&
SIDE_HASH7=$(git rev-parse --verify HEAD)
'
test_expect_success 'good merge base when good and bad are siblings' '
git bisect start "$HASH7" "$SIDE_HASH7" > my_bisect_log.txt &&
test_i18ngrep "merge base must be tested" my_bisect_log.txt &&
bisect: test merge base if good rev is not an ancestor of bad rev Before this patch, "git bisect", when it was given some good revs that are not ancestor of the bad rev, didn't check if the merge bases were good. "git bisect" just supposed that the user knew what he was doing, and that, when he said the revs were good, he knew that it meant that all the revs in the history leading to the good revs were also considered good. But in pratice, the user may not know that a good rev is not an ancestor of the bad rev, or he may not know/remember that all revs leading to the good rev will be considered good. So he may give a good rev that is a sibling, instead of an ancestor, of the bad rev, when in fact there can be one rev becoming good in the branch of the good rev (because the bug was already fixed there, for example) instead of one rev becoming bad in the branch of the bad rev. For example, if there is the following history: A--B--C--D \ E--F and we launch "git bisect start D F" then only C and D would have been considered as possible first bad commit before this patch. This could invite user errors; F could be the commit that fixes the bug that exists everywhere else. The purpose of this patch is to detect when "git bisect" is passed some good revs that are not ancestors of the bad rev, and then to first ask the user to test the merge bases between the good and bad revs. If the merge bases are good then all is fine, we can continue bisecting. Otherwise, if one merge base is bad, it means that the assumption that all revs leading to the good one are good too is wrong and we error out. In the case where one merge base is skipped we issue a warning and then continue bisecting anyway. These checks will also catch the case where good and bad have been mistaken. This means that we can remove the check that was done latter on the output of "git rev-list --bisect-vars". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-22 03:52:22 +00:00
grep $HASH4 my_bisect_log.txt &&
git bisect good > my_bisect_log.txt &&
! grep "merge base must be tested" my_bisect_log.txt &&
bisect: test merge base if good rev is not an ancestor of bad rev Before this patch, "git bisect", when it was given some good revs that are not ancestor of the bad rev, didn't check if the merge bases were good. "git bisect" just supposed that the user knew what he was doing, and that, when he said the revs were good, he knew that it meant that all the revs in the history leading to the good revs were also considered good. But in pratice, the user may not know that a good rev is not an ancestor of the bad rev, or he may not know/remember that all revs leading to the good rev will be considered good. So he may give a good rev that is a sibling, instead of an ancestor, of the bad rev, when in fact there can be one rev becoming good in the branch of the good rev (because the bug was already fixed there, for example) instead of one rev becoming bad in the branch of the bad rev. For example, if there is the following history: A--B--C--D \ E--F and we launch "git bisect start D F" then only C and D would have been considered as possible first bad commit before this patch. This could invite user errors; F could be the commit that fixes the bug that exists everywhere else. The purpose of this patch is to detect when "git bisect" is passed some good revs that are not ancestors of the bad rev, and then to first ask the user to test the merge bases between the good and bad revs. If the merge bases are good then all is fine, we can continue bisecting. Otherwise, if one merge base is bad, it means that the assumption that all revs leading to the good one are good too is wrong and we error out. In the case where one merge base is skipped we issue a warning and then continue bisecting anyway. These checks will also catch the case where good and bad have been mistaken. This means that we can remove the check that was done latter on the output of "git rev-list --bisect-vars". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-22 03:52:22 +00:00
grep $HASH6 my_bisect_log.txt &&
git bisect reset
'
test_expect_success 'skipped merge base when good and bad are siblings' '
git bisect start "$SIDE_HASH7" "$HASH7" > my_bisect_log.txt &&
test_i18ngrep "merge base must be tested" my_bisect_log.txt &&
bisect: test merge base if good rev is not an ancestor of bad rev Before this patch, "git bisect", when it was given some good revs that are not ancestor of the bad rev, didn't check if the merge bases were good. "git bisect" just supposed that the user knew what he was doing, and that, when he said the revs were good, he knew that it meant that all the revs in the history leading to the good revs were also considered good. But in pratice, the user may not know that a good rev is not an ancestor of the bad rev, or he may not know/remember that all revs leading to the good rev will be considered good. So he may give a good rev that is a sibling, instead of an ancestor, of the bad rev, when in fact there can be one rev becoming good in the branch of the good rev (because the bug was already fixed there, for example) instead of one rev becoming bad in the branch of the bad rev. For example, if there is the following history: A--B--C--D \ E--F and we launch "git bisect start D F" then only C and D would have been considered as possible first bad commit before this patch. This could invite user errors; F could be the commit that fixes the bug that exists everywhere else. The purpose of this patch is to detect when "git bisect" is passed some good revs that are not ancestors of the bad rev, and then to first ask the user to test the merge bases between the good and bad revs. If the merge bases are good then all is fine, we can continue bisecting. Otherwise, if one merge base is bad, it means that the assumption that all revs leading to the good one are good too is wrong and we error out. In the case where one merge base is skipped we issue a warning and then continue bisecting anyway. These checks will also catch the case where good and bad have been mistaken. This means that we can remove the check that was done latter on the output of "git rev-list --bisect-vars". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-22 03:52:22 +00:00
grep $HASH4 my_bisect_log.txt &&
git bisect skip > my_bisect_log.txt 2>&1 &&
grep "warning" my_bisect_log.txt &&
bisect: test merge base if good rev is not an ancestor of bad rev Before this patch, "git bisect", when it was given some good revs that are not ancestor of the bad rev, didn't check if the merge bases were good. "git bisect" just supposed that the user knew what he was doing, and that, when he said the revs were good, he knew that it meant that all the revs in the history leading to the good revs were also considered good. But in pratice, the user may not know that a good rev is not an ancestor of the bad rev, or he may not know/remember that all revs leading to the good rev will be considered good. So he may give a good rev that is a sibling, instead of an ancestor, of the bad rev, when in fact there can be one rev becoming good in the branch of the good rev (because the bug was already fixed there, for example) instead of one rev becoming bad in the branch of the bad rev. For example, if there is the following history: A--B--C--D \ E--F and we launch "git bisect start D F" then only C and D would have been considered as possible first bad commit before this patch. This could invite user errors; F could be the commit that fixes the bug that exists everywhere else. The purpose of this patch is to detect when "git bisect" is passed some good revs that are not ancestors of the bad rev, and then to first ask the user to test the merge bases between the good and bad revs. If the merge bases are good then all is fine, we can continue bisecting. Otherwise, if one merge base is bad, it means that the assumption that all revs leading to the good one are good too is wrong and we error out. In the case where one merge base is skipped we issue a warning and then continue bisecting anyway. These checks will also catch the case where good and bad have been mistaken. This means that we can remove the check that was done latter on the output of "git rev-list --bisect-vars". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-22 03:52:22 +00:00
grep $SIDE_HASH6 my_bisect_log.txt &&
git bisect reset
'
test_expect_success 'bad merge base when good and bad are siblings' '
git bisect start "$HASH7" HEAD > my_bisect_log.txt &&
test_i18ngrep "merge base must be tested" my_bisect_log.txt &&
bisect: test merge base if good rev is not an ancestor of bad rev Before this patch, "git bisect", when it was given some good revs that are not ancestor of the bad rev, didn't check if the merge bases were good. "git bisect" just supposed that the user knew what he was doing, and that, when he said the revs were good, he knew that it meant that all the revs in the history leading to the good revs were also considered good. But in pratice, the user may not know that a good rev is not an ancestor of the bad rev, or he may not know/remember that all revs leading to the good rev will be considered good. So he may give a good rev that is a sibling, instead of an ancestor, of the bad rev, when in fact there can be one rev becoming good in the branch of the good rev (because the bug was already fixed there, for example) instead of one rev becoming bad in the branch of the bad rev. For example, if there is the following history: A--B--C--D \ E--F and we launch "git bisect start D F" then only C and D would have been considered as possible first bad commit before this patch. This could invite user errors; F could be the commit that fixes the bug that exists everywhere else. The purpose of this patch is to detect when "git bisect" is passed some good revs that are not ancestors of the bad rev, and then to first ask the user to test the merge bases between the good and bad revs. If the merge bases are good then all is fine, we can continue bisecting. Otherwise, if one merge base is bad, it means that the assumption that all revs leading to the good one are good too is wrong and we error out. In the case where one merge base is skipped we issue a warning and then continue bisecting anyway. These checks will also catch the case where good and bad have been mistaken. This means that we can remove the check that was done latter on the output of "git rev-list --bisect-vars". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-22 03:52:22 +00:00
grep $HASH4 my_bisect_log.txt &&
test_must_fail git bisect bad > my_bisect_log.txt 2>&1 &&
test_i18ngrep "merge base $HASH4 is bad" my_bisect_log.txt &&
test_i18ngrep "fixed between $HASH4 and \[$SIDE_HASH7\]" my_bisect_log.txt &&
bisect: test merge base if good rev is not an ancestor of bad rev Before this patch, "git bisect", when it was given some good revs that are not ancestor of the bad rev, didn't check if the merge bases were good. "git bisect" just supposed that the user knew what he was doing, and that, when he said the revs were good, he knew that it meant that all the revs in the history leading to the good revs were also considered good. But in pratice, the user may not know that a good rev is not an ancestor of the bad rev, or he may not know/remember that all revs leading to the good rev will be considered good. So he may give a good rev that is a sibling, instead of an ancestor, of the bad rev, when in fact there can be one rev becoming good in the branch of the good rev (because the bug was already fixed there, for example) instead of one rev becoming bad in the branch of the bad rev. For example, if there is the following history: A--B--C--D \ E--F and we launch "git bisect start D F" then only C and D would have been considered as possible first bad commit before this patch. This could invite user errors; F could be the commit that fixes the bug that exists everywhere else. The purpose of this patch is to detect when "git bisect" is passed some good revs that are not ancestors of the bad rev, and then to first ask the user to test the merge bases between the good and bad revs. If the merge bases are good then all is fine, we can continue bisecting. Otherwise, if one merge base is bad, it means that the assumption that all revs leading to the good one are good too is wrong and we error out. In the case where one merge base is skipped we issue a warning and then continue bisecting anyway. These checks will also catch the case where good and bad have been mistaken. This means that we can remove the check that was done latter on the output of "git rev-list --bisect-vars". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-22 03:52:22 +00:00
git bisect reset
'
# This creates a few more commits (A and B) to test "siblings" cases
# when a good and a bad rev have many merge bases.
#
# We should have the following:
#
# H1-H2-H3-H4-H5-H6-H7
# \ \ \
# S5-A \
# \ \
# S6-S7----B
#
# And there A and B have 2 merge bases (S5 and H5) that should be
# reported by "git merge-base --all A B".
#
test_expect_success 'many merge bases creation' '
git checkout "$SIDE_HASH5" &&
git merge -m "merge HASH5 and SIDE_HASH5" "$HASH5" &&
A_HASH=$(git rev-parse --verify HEAD) &&
git checkout side &&
git merge -m "merge HASH7 and SIDE_HASH7" "$HASH7" &&
B_HASH=$(git rev-parse --verify HEAD) &&
git merge-base --all "$A_HASH" "$B_HASH" > merge_bases.txt &&
test_line_count = 2 merge_bases.txt &&
bisect: test merge base if good rev is not an ancestor of bad rev Before this patch, "git bisect", when it was given some good revs that are not ancestor of the bad rev, didn't check if the merge bases were good. "git bisect" just supposed that the user knew what he was doing, and that, when he said the revs were good, he knew that it meant that all the revs in the history leading to the good revs were also considered good. But in pratice, the user may not know that a good rev is not an ancestor of the bad rev, or he may not know/remember that all revs leading to the good rev will be considered good. So he may give a good rev that is a sibling, instead of an ancestor, of the bad rev, when in fact there can be one rev becoming good in the branch of the good rev (because the bug was already fixed there, for example) instead of one rev becoming bad in the branch of the bad rev. For example, if there is the following history: A--B--C--D \ E--F and we launch "git bisect start D F" then only C and D would have been considered as possible first bad commit before this patch. This could invite user errors; F could be the commit that fixes the bug that exists everywhere else. The purpose of this patch is to detect when "git bisect" is passed some good revs that are not ancestors of the bad rev, and then to first ask the user to test the merge bases between the good and bad revs. If the merge bases are good then all is fine, we can continue bisecting. Otherwise, if one merge base is bad, it means that the assumption that all revs leading to the good one are good too is wrong and we error out. In the case where one merge base is skipped we issue a warning and then continue bisecting anyway. These checks will also catch the case where good and bad have been mistaken. This means that we can remove the check that was done latter on the output of "git rev-list --bisect-vars". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-22 03:52:22 +00:00
grep "$HASH5" merge_bases.txt &&
grep "$SIDE_HASH5" merge_bases.txt
'
# We want to automatically find the merge that
# added "line" into hello.
test_expect_success '"git bisect run --first-parent" simple case' '
git rev-list --first-parent $B_HASH ^$HASH4 >first_parent_chain.txt &&
write_script test_script.sh <<-\EOF &&
grep $(git rev-parse HEAD) first_parent_chain.txt || exit -1
! grep line hello >/dev/null
EOF
git bisect start --first-parent &&
test_path_is_file ".git/BISECT_FIRST_PARENT" &&
git bisect good $HASH4 &&
git bisect bad $B_HASH &&
git bisect run ./test_script.sh >my_bisect_log.txt &&
grep "$B_HASH is the first bad commit" my_bisect_log.txt &&
git bisect reset &&
test_path_is_missing .git/BISECT_FIRST_PARENT
'
bisect: test merge base if good rev is not an ancestor of bad rev Before this patch, "git bisect", when it was given some good revs that are not ancestor of the bad rev, didn't check if the merge bases were good. "git bisect" just supposed that the user knew what he was doing, and that, when he said the revs were good, he knew that it meant that all the revs in the history leading to the good revs were also considered good. But in pratice, the user may not know that a good rev is not an ancestor of the bad rev, or he may not know/remember that all revs leading to the good rev will be considered good. So he may give a good rev that is a sibling, instead of an ancestor, of the bad rev, when in fact there can be one rev becoming good in the branch of the good rev (because the bug was already fixed there, for example) instead of one rev becoming bad in the branch of the bad rev. For example, if there is the following history: A--B--C--D \ E--F and we launch "git bisect start D F" then only C and D would have been considered as possible first bad commit before this patch. This could invite user errors; F could be the commit that fixes the bug that exists everywhere else. The purpose of this patch is to detect when "git bisect" is passed some good revs that are not ancestors of the bad rev, and then to first ask the user to test the merge bases between the good and bad revs. If the merge bases are good then all is fine, we can continue bisecting. Otherwise, if one merge base is bad, it means that the assumption that all revs leading to the good one are good too is wrong and we error out. In the case where one merge base is skipped we issue a warning and then continue bisecting anyway. These checks will also catch the case where good and bad have been mistaken. This means that we can remove the check that was done latter on the output of "git rev-list --bisect-vars". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-22 03:52:22 +00:00
test_expect_success 'good merge bases when good and bad are siblings' '
git bisect start "$B_HASH" "$A_HASH" > my_bisect_log.txt &&
test_i18ngrep "merge base must be tested" my_bisect_log.txt &&
bisect: test merge base if good rev is not an ancestor of bad rev Before this patch, "git bisect", when it was given some good revs that are not ancestor of the bad rev, didn't check if the merge bases were good. "git bisect" just supposed that the user knew what he was doing, and that, when he said the revs were good, he knew that it meant that all the revs in the history leading to the good revs were also considered good. But in pratice, the user may not know that a good rev is not an ancestor of the bad rev, or he may not know/remember that all revs leading to the good rev will be considered good. So he may give a good rev that is a sibling, instead of an ancestor, of the bad rev, when in fact there can be one rev becoming good in the branch of the good rev (because the bug was already fixed there, for example) instead of one rev becoming bad in the branch of the bad rev. For example, if there is the following history: A--B--C--D \ E--F and we launch "git bisect start D F" then only C and D would have been considered as possible first bad commit before this patch. This could invite user errors; F could be the commit that fixes the bug that exists everywhere else. The purpose of this patch is to detect when "git bisect" is passed some good revs that are not ancestors of the bad rev, and then to first ask the user to test the merge bases between the good and bad revs. If the merge bases are good then all is fine, we can continue bisecting. Otherwise, if one merge base is bad, it means that the assumption that all revs leading to the good one are good too is wrong and we error out. In the case where one merge base is skipped we issue a warning and then continue bisecting anyway. These checks will also catch the case where good and bad have been mistaken. This means that we can remove the check that was done latter on the output of "git rev-list --bisect-vars". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-22 03:52:22 +00:00
git bisect good > my_bisect_log2.txt &&
test_i18ngrep "merge base must be tested" my_bisect_log2.txt &&
bisect: test merge base if good rev is not an ancestor of bad rev Before this patch, "git bisect", when it was given some good revs that are not ancestor of the bad rev, didn't check if the merge bases were good. "git bisect" just supposed that the user knew what he was doing, and that, when he said the revs were good, he knew that it meant that all the revs in the history leading to the good revs were also considered good. But in pratice, the user may not know that a good rev is not an ancestor of the bad rev, or he may not know/remember that all revs leading to the good rev will be considered good. So he may give a good rev that is a sibling, instead of an ancestor, of the bad rev, when in fact there can be one rev becoming good in the branch of the good rev (because the bug was already fixed there, for example) instead of one rev becoming bad in the branch of the bad rev. For example, if there is the following history: A--B--C--D \ E--F and we launch "git bisect start D F" then only C and D would have been considered as possible first bad commit before this patch. This could invite user errors; F could be the commit that fixes the bug that exists everywhere else. The purpose of this patch is to detect when "git bisect" is passed some good revs that are not ancestors of the bad rev, and then to first ask the user to test the merge bases between the good and bad revs. If the merge bases are good then all is fine, we can continue bisecting. Otherwise, if one merge base is bad, it means that the assumption that all revs leading to the good one are good too is wrong and we error out. In the case where one merge base is skipped we issue a warning and then continue bisecting anyway. These checks will also catch the case where good and bad have been mistaken. This means that we can remove the check that was done latter on the output of "git rev-list --bisect-vars". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-22 03:52:22 +00:00
{
{
grep "$SIDE_HASH5" my_bisect_log.txt &&
grep "$HASH5" my_bisect_log2.txt
} || {
grep "$SIDE_HASH5" my_bisect_log2.txt &&
grep "$HASH5" my_bisect_log.txt
}
} &&
git bisect reset
'
test_expect_success 'optimized merge base checks' '
git bisect start "$HASH7" "$SIDE_HASH7" > my_bisect_log.txt &&
test_i18ngrep "merge base must be tested" my_bisect_log.txt &&
grep "$HASH4" my_bisect_log.txt &&
git bisect good > my_bisect_log2.txt &&
test -f ".git/BISECT_ANCESTORS_OK" &&
test "$HASH6" = $(git rev-parse --verify HEAD) &&
git bisect bad &&
git bisect good "$A_HASH" > my_bisect_log4.txt &&
test_i18ngrep "merge base must be tested" my_bisect_log4.txt &&
test_path_is_missing ".git/BISECT_ANCESTORS_OK"
'
# This creates another side branch called "parallel" with some files
# in some directories, to test bisecting with paths.
#
# We should have the following:
#
# P1-P2-P3-P4-P5-P6-P7
# / / /
# H1-H2-H3-H4-H5-H6-H7
# \ \ \
# S5-A \
# \ \
# S6-S7----B
#
test_expect_success '"parallel" side branch creation' '
git bisect reset &&
git checkout -b parallel $HASH1 &&
mkdir dir1 dir2 &&
add_line_into_file "1(para): line 1 on parallel branch" dir1/file1 &&
PARA_HASH1=$(git rev-parse --verify HEAD) &&
add_line_into_file "2(para): line 2 on parallel branch" dir2/file2 &&
PARA_HASH2=$(git rev-parse --verify HEAD) &&
add_line_into_file "3(para): line 3 on parallel branch" dir2/file3 &&
PARA_HASH3=$(git rev-parse --verify HEAD) &&
git merge -m "merge HASH4 and PARA_HASH3" "$HASH4" &&
PARA_HASH4=$(git rev-parse --verify HEAD) &&
add_line_into_file "5(para): add line on parallel branch" dir1/file1 &&
PARA_HASH5=$(git rev-parse --verify HEAD) &&
add_line_into_file "6(para): add line on parallel branch" dir2/file2 &&
PARA_HASH6=$(git rev-parse --verify HEAD) &&
git merge -m "merge HASH7 and PARA_HASH6" "$HASH7" &&
PARA_HASH7=$(git rev-parse --verify HEAD)
'
test_expect_success 'restricting bisection on one dir' '
git bisect reset &&
git bisect start HEAD $HASH1 -- dir1 &&
para1=$(git rev-parse --verify HEAD) &&
test "$para1" = "$PARA_HASH1" &&
git bisect bad > my_bisect_log.txt &&
grep "$PARA_HASH1 is the first bad commit" my_bisect_log.txt
'
test_expect_success 'restricting bisection on one dir and a file' '
git bisect reset &&
git bisect start HEAD $HASH1 -- dir1 hello &&
para4=$(git rev-parse --verify HEAD) &&
test "$para4" = "$PARA_HASH4" &&
git bisect bad &&
hash3=$(git rev-parse --verify HEAD) &&
test "$hash3" = "$HASH3" &&
git bisect good &&
hash4=$(git rev-parse --verify HEAD) &&
test "$hash4" = "$HASH4" &&
git bisect good &&
para1=$(git rev-parse --verify HEAD) &&
test "$para1" = "$PARA_HASH1" &&
git bisect good > my_bisect_log.txt &&
grep "$PARA_HASH4 is the first bad commit" my_bisect_log.txt
'
test_expect_success 'skipping away from skipped commit' '
git bisect start $PARA_HASH7 $HASH1 &&
para4=$(git rev-parse --verify HEAD) &&
test "$para4" = "$PARA_HASH4" &&
git bisect skip &&
hash7=$(git rev-parse --verify HEAD) &&
test "$hash7" = "$HASH7" &&
git bisect skip &&
para3=$(git rev-parse --verify HEAD) &&
test "$para3" = "$PARA_HASH3"
'
test_expect_success 'erroring out when using bad path arguments' '
test_must_fail git bisect start $PARA_HASH7 $HASH1 -- foobar 2> error.txt &&
test_i18ngrep "bad path arguments" error.txt
'
test_expect_success 'test bisection on bare repo - --no-checkout specified' '
git clone --bare . bare.nocheckout &&
(
cd bare.nocheckout &&
git bisect start --no-checkout &&
git bisect good $HASH1 &&
git bisect bad $HASH4 &&
git bisect run eval \
"test \$(git rev-list BISECT_HEAD ^$HASH2 --max-count=1 | wc -l) = 0" \
>../nocheckout.log
) &&
grep "$HASH3 is the first bad commit" nocheckout.log
'
test_expect_success 'test bisection on bare repo - --no-checkout defaulted' '
git clone --bare . bare.defaulted &&
(
cd bare.defaulted &&
git bisect start &&
git bisect good $HASH1 &&
git bisect bad $HASH4 &&
git bisect run eval \
"test \$(git rev-list BISECT_HEAD ^$HASH2 --max-count=1 | wc -l) = 0" \
>../defaulted.log
) &&
grep "$HASH3 is the first bad commit" defaulted.log
'
#
# This creates a broken branch which cannot be checked out because
# the tree created has been deleted.
#
# H1-H2-H3-H4-H5-H6-H7 <--other
# \
# S5-S6'-S7'-S8'-S9 <--broken
#
# Commits marked with ' have a missing tree.
#
test_expect_success 'broken branch creation' '
git bisect reset &&
git checkout -b broken $HASH4 &&
git tag BROKEN_HASH4 $HASH4 &&
add_line_into_file "5(broken): first line on a broken branch" hello2 &&
git tag BROKEN_HASH5 &&
mkdir missing &&
:> missing/MISSING &&
git add missing/MISSING &&
git commit -m "6(broken): Added file that will be deleted" &&
git tag BROKEN_HASH6 &&
deleted=$(git rev-parse --verify HEAD:missing) &&
add_line_into_file "7(broken): second line on a broken branch" hello2 &&
git tag BROKEN_HASH7 &&
add_line_into_file "8(broken): third line on a broken branch" hello2 &&
git tag BROKEN_HASH8 &&
git rm missing/MISSING &&
git commit -m "9(broken): Remove missing file" &&
git tag BROKEN_HASH9 &&
rm .git/objects/$(test_oid_to_path $deleted)
'
echo "" > expected.ok
cat > expected.missing-tree.default <<EOF
fatal: unable to read tree $deleted
EOF
test_expect_success 'bisect fails if tree is broken on start commit' '
git bisect reset &&
test_must_fail git bisect start BROKEN_HASH7 BROKEN_HASH4 2>error.txt &&
test_cmp expected.missing-tree.default error.txt
'
test_expect_success 'bisect fails if tree is broken on trial commit' '
git bisect reset &&
test_must_fail git bisect start BROKEN_HASH9 BROKEN_HASH4 2>error.txt &&
git reset --hard broken &&
git checkout broken &&
test_cmp expected.missing-tree.default error.txt
'
check_same()
{
echo "Checking $1 is the same as $2" &&
test_cmp_rev "$1" "$2"
}
test_expect_success 'bisect: --no-checkout - start commit bad' '
git bisect reset &&
git bisect start BROKEN_HASH7 BROKEN_HASH4 --no-checkout &&
check_same BROKEN_HASH6 BISECT_HEAD &&
git bisect reset
'
test_expect_success 'bisect: --no-checkout - trial commit bad' '
git bisect reset &&
git bisect start broken BROKEN_HASH4 --no-checkout &&
check_same BROKEN_HASH6 BISECT_HEAD &&
git bisect reset
'
test_expect_success 'bisect: --no-checkout - target before breakage' '
git bisect reset &&
git bisect start broken BROKEN_HASH4 --no-checkout &&
check_same BROKEN_HASH6 BISECT_HEAD &&
git bisect bad BISECT_HEAD &&
check_same BROKEN_HASH5 BISECT_HEAD &&
git bisect bad BISECT_HEAD &&
check_same BROKEN_HASH5 bisect/bad &&
git bisect reset
'
test_expect_success 'bisect: --no-checkout - target in breakage' '
git bisect reset &&
git bisect start broken BROKEN_HASH4 --no-checkout &&
check_same BROKEN_HASH6 BISECT_HEAD &&
git bisect bad BISECT_HEAD &&
check_same BROKEN_HASH5 BISECT_HEAD &&
bisect: make diff-tree output prettier After completing a bisection, we print out the commit we found using an internal version of diff-tree. The result is aesthetically lacking: - it shows a raw diff, which is generally less informative for human readers than "--stat --summary" (which we already decided was nice for humans in format-patch's output). - by not abbreviating hashes, the result is likely to wrap on most people's terminals - we don't use "-r", so if the commit touched files in a directory, you only get to see the top-level directory mentioned - we don't specify "--cc" or similar, so merges print nothing (not even the commit message!) Even though bisect might be driven by scripts, there's no reason to consider this part of the output as machine-readable (if anything, the initial "$hash is the first bad commit" might be parsed, but we won't touch that here). Let's make it prettier and more informative for a human reading the output. While we're tweaking the options, let's also switch to using the diff "ui" config. If we're accepting that this is human-readable output, then we should respect the user's options for how to display it. Note that we have to touch a few tests in t6030. These check bisection in a corrupted repository (it's missing a subtree). They didn't fail with the previous code, because it didn't actually recurse far enough in the diff to find the broken tree. But now we'll see the corruption and complain. Adjusting the tests to expect the die() is the best fix. We still confirm that we're able to bisect within the broken repo. And we'll still print "$hash is the first bad commit" as usual before dying; showing that is a reasonable outcome in a corrupt repository (and was what might happen already, if the root tree was corrupt). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-22 06:23:28 +00:00
test_must_fail git bisect good BISECT_HEAD &&
check_same BROKEN_HASH6 bisect/bad &&
git bisect reset
'
test_expect_success 'bisect: --no-checkout - target after breakage' '
git bisect reset &&
git bisect start broken BROKEN_HASH4 --no-checkout &&
check_same BROKEN_HASH6 BISECT_HEAD &&
git bisect good BISECT_HEAD &&
check_same BROKEN_HASH8 BISECT_HEAD &&
bisect: make diff-tree output prettier After completing a bisection, we print out the commit we found using an internal version of diff-tree. The result is aesthetically lacking: - it shows a raw diff, which is generally less informative for human readers than "--stat --summary" (which we already decided was nice for humans in format-patch's output). - by not abbreviating hashes, the result is likely to wrap on most people's terminals - we don't use "-r", so if the commit touched files in a directory, you only get to see the top-level directory mentioned - we don't specify "--cc" or similar, so merges print nothing (not even the commit message!) Even though bisect might be driven by scripts, there's no reason to consider this part of the output as machine-readable (if anything, the initial "$hash is the first bad commit" might be parsed, but we won't touch that here). Let's make it prettier and more informative for a human reading the output. While we're tweaking the options, let's also switch to using the diff "ui" config. If we're accepting that this is human-readable output, then we should respect the user's options for how to display it. Note that we have to touch a few tests in t6030. These check bisection in a corrupted repository (it's missing a subtree). They didn't fail with the previous code, because it didn't actually recurse far enough in the diff to find the broken tree. But now we'll see the corruption and complain. Adjusting the tests to expect the die() is the best fix. We still confirm that we're able to bisect within the broken repo. And we'll still print "$hash is the first bad commit" as usual before dying; showing that is a reasonable outcome in a corrupt repository (and was what might happen already, if the root tree was corrupt). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-22 06:23:28 +00:00
test_must_fail git bisect good BISECT_HEAD &&
check_same BROKEN_HASH9 bisect/bad &&
git bisect reset
'
test_expect_success 'bisect: demonstrate identification of damage boundary' "
git bisect reset &&
git checkout broken &&
git bisect start broken main --no-checkout &&
bisect: make diff-tree output prettier After completing a bisection, we print out the commit we found using an internal version of diff-tree. The result is aesthetically lacking: - it shows a raw diff, which is generally less informative for human readers than "--stat --summary" (which we already decided was nice for humans in format-patch's output). - by not abbreviating hashes, the result is likely to wrap on most people's terminals - we don't use "-r", so if the commit touched files in a directory, you only get to see the top-level directory mentioned - we don't specify "--cc" or similar, so merges print nothing (not even the commit message!) Even though bisect might be driven by scripts, there's no reason to consider this part of the output as machine-readable (if anything, the initial "$hash is the first bad commit" might be parsed, but we won't touch that here). Let's make it prettier and more informative for a human reading the output. While we're tweaking the options, let's also switch to using the diff "ui" config. If we're accepting that this is human-readable output, then we should respect the user's options for how to display it. Note that we have to touch a few tests in t6030. These check bisection in a corrupted repository (it's missing a subtree). They didn't fail with the previous code, because it didn't actually recurse far enough in the diff to find the broken tree. But now we'll see the corruption and complain. Adjusting the tests to expect the die() is the best fix. We still confirm that we're able to bisect within the broken repo. And we'll still print "$hash is the first bad commit" as usual before dying; showing that is a reasonable outcome in a corrupt repository (and was what might happen already, if the root tree was corrupt). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-22 06:23:28 +00:00
test_must_fail git bisect run \"\$SHELL_PATH\" -c '
GOOD=\$(git for-each-ref \"--format=%(objectname)\" refs/bisect/good-*) &&
git rev-list --objects BISECT_HEAD --not \$GOOD >tmp.\$\$ &&
git pack-objects --stdout >/dev/null < tmp.\$\$
rc=\$?
rm -f tmp.\$\$
test \$rc = 0' &&
check_same BROKEN_HASH6 bisect/bad &&
git bisect reset
"
cat > expected.bisect-log <<EOF
# bad: [$HASH4] Add <4: Ciao for now> into <hello>.
# good: [$HASH2] Add <2: A new day for git> into <hello>.
git bisect start '$HASH4' '$HASH2'
# good: [$HASH3] Add <3: Another new day for git> into <hello>.
git bisect good $HASH3
# first bad commit: [$HASH4] Add <4: Ciao for now> into <hello>.
EOF
test_expect_success 'bisect log: successful result' '
git bisect reset &&
git bisect start $HASH4 $HASH2 &&
git bisect good &&
git bisect log >bisect-log.txt &&
test_cmp expected.bisect-log bisect-log.txt &&
git bisect reset
'
cat > expected.bisect-skip-log <<EOF
# bad: [$HASH4] Add <4: Ciao for now> into <hello>.
# good: [$HASH2] Add <2: A new day for git> into <hello>.
git bisect start '$HASH4' '$HASH2'
# skip: [$HASH3] Add <3: Another new day for git> into <hello>.
git bisect skip $HASH3
# only skipped commits left to test
# possible first bad commit: [$HASH4] Add <4: Ciao for now> into <hello>.
# possible first bad commit: [$HASH3] Add <3: Another new day for git> into <hello>.
EOF
test_expect_success 'bisect log: only skip commits left' '
git bisect reset &&
git bisect start $HASH4 $HASH2 &&
test_must_fail git bisect skip &&
git bisect log >bisect-skip-log.txt &&
test_cmp expected.bisect-skip-log bisect-skip-log.txt &&
git bisect reset
'
test_expect_success '"git bisect bad HEAD" behaves as "git bisect bad"' '
git checkout parallel &&
git bisect start HEAD $HASH1 &&
git bisect good HEAD &&
git bisect bad HEAD &&
test "$HASH6" = $(git rev-parse --verify HEAD) &&
git bisect reset
'
bisect: add the terms old/new When not looking for a regression during a bisect but for a fix or a change in another given property, it can be confusing to use 'good' and 'bad'. This patch introduce `git bisect new` and `git bisect old` as an alternative to 'bad' and good': the commits which have a certain property must be marked as `new` and the ones which do not as `old`. The output will be the first commit after the change in the property. During a new/old bisect session you cannot use bad/good commands and vice-versa. Some commands are still not available for old/new: * git rev-list --bisect does not treat the revs/bisect/new and revs/bisect/old-SHA1 files. Old discussions: - http://thread.gmane.org/gmane.comp.version-control.git/86063 introduced bisect fix unfixed to find fix. - http://thread.gmane.org/gmane.comp.version-control.git/182398 discussion around bisect yes/no or old/new. - http://thread.gmane.org/gmane.comp.version-control.git/199758 last discussion and reviews New discussions: - http://thread.gmane.org/gmane.comp.version-control.git/271320 ( v2 1/7-4/7 ) - http://comments.gmane.org/gmane.comp.version-control.git/271343 ( v2 5/7-7/7 ) Signed-off-by: Antoine Delaite <antoine.delaite@ensimag.grenoble-inp.fr> Signed-off-by: Louis Stuber <stuberl@ensimag.grenoble-inp.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-29 15:40:33 +00:00
test_expect_success 'bisect starts with only one new' '
git bisect reset &&
git bisect start &&
git bisect new $HASH4 &&
git bisect next
'
test_expect_success 'bisect does not start with only one old' '
git bisect reset &&
git bisect start &&
git bisect old $HASH1 &&
test_must_fail git bisect next
'
test_expect_success 'bisect start with one new and old' '
git bisect reset &&
git bisect start &&
git bisect old $HASH1 &&
git bisect new $HASH4 &&
git bisect new &&
git bisect new >bisect_result &&
grep "$HASH2 is the first new commit" bisect_result &&
git bisect log >log_to_replay.txt &&
git bisect reset
'
test_expect_success 'bisect replay with old and new' '
git bisect replay log_to_replay.txt >bisect_result &&
grep "$HASH2 is the first new commit" bisect_result &&
git bisect reset
'
test_expect_success 'bisect replay with CRLF log' '
append_cr <log_to_replay.txt >log_to_replay_crlf.txt &&
git bisect replay log_to_replay_crlf.txt >bisect_result_crlf &&
grep "$HASH2 is the first new commit" bisect_result_crlf &&
git bisect reset
'
bisect: add the terms old/new When not looking for a regression during a bisect but for a fix or a change in another given property, it can be confusing to use 'good' and 'bad'. This patch introduce `git bisect new` and `git bisect old` as an alternative to 'bad' and good': the commits which have a certain property must be marked as `new` and the ones which do not as `old`. The output will be the first commit after the change in the property. During a new/old bisect session you cannot use bad/good commands and vice-versa. Some commands are still not available for old/new: * git rev-list --bisect does not treat the revs/bisect/new and revs/bisect/old-SHA1 files. Old discussions: - http://thread.gmane.org/gmane.comp.version-control.git/86063 introduced bisect fix unfixed to find fix. - http://thread.gmane.org/gmane.comp.version-control.git/182398 discussion around bisect yes/no or old/new. - http://thread.gmane.org/gmane.comp.version-control.git/199758 last discussion and reviews New discussions: - http://thread.gmane.org/gmane.comp.version-control.git/271320 ( v2 1/7-4/7 ) - http://comments.gmane.org/gmane.comp.version-control.git/271343 ( v2 5/7-7/7 ) Signed-off-by: Antoine Delaite <antoine.delaite@ensimag.grenoble-inp.fr> Signed-off-by: Louis Stuber <stuberl@ensimag.grenoble-inp.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-29 15:40:33 +00:00
test_expect_success 'bisect cannot mix old/new and good/bad' '
git bisect start &&
git bisect bad $HASH4 &&
test_must_fail git bisect old $HASH1
'
test_expect_success 'bisect terms needs 0 or 1 argument' '
git bisect reset &&
test_must_fail git bisect terms only-one &&
test_must_fail git bisect terms 1 2 &&
test_must_fail git bisect terms 2>actual &&
echo "error: no terms defined" >expected &&
test_cmp expected actual
'
test_expect_success 'bisect terms shows good/bad after start' '
git bisect reset &&
git bisect start HEAD $HASH1 &&
git bisect terms --term-good >actual &&
echo good >expected &&
test_cmp expected actual &&
git bisect terms --term-bad >actual &&
echo bad >expected &&
test_cmp expected actual
'
test_expect_success 'bisect start with one term1 and term2' '
git bisect reset &&
git bisect start --term-old term2 --term-new term1 &&
git bisect term2 $HASH1 &&
git bisect term1 $HASH4 &&
git bisect term1 &&
git bisect term1 >bisect_result &&
grep "$HASH2 is the first term1 commit" bisect_result &&
git bisect log >log_to_replay.txt &&
git bisect reset
'
test_expect_success 'bisect replay with term1 and term2' '
git bisect replay log_to_replay.txt >bisect_result &&
grep "$HASH2 is the first term1 commit" bisect_result &&
git bisect reset
'
test_expect_success 'bisect start term1 term2' '
git bisect reset &&
git bisect start --term-new term1 --term-old term2 $HASH4 $HASH1 &&
git bisect term1 &&
git bisect term1 >bisect_result &&
grep "$HASH2 is the first term1 commit" bisect_result &&
git bisect log >log_to_replay.txt &&
git bisect reset
'
test_expect_success 'bisect cannot mix terms' '
git bisect reset &&
git bisect start --term-good term1 --term-bad term2 $HASH4 $HASH1 &&
test_must_fail git bisect a &&
test_must_fail git bisect b &&
test_must_fail git bisect bad &&
test_must_fail git bisect good &&
test_must_fail git bisect new &&
test_must_fail git bisect old
'
test_expect_success 'bisect terms rejects invalid terms' '
git bisect reset &&
test_must_fail git bisect start --term-good &&
test_must_fail git bisect start --term-good invalid..term &&
test_must_fail git bisect start --term-bad &&
test_must_fail git bisect terms --term-bad invalid..term &&
test_must_fail git bisect terms --term-good bad &&
test_must_fail git bisect terms --term-good old &&
test_must_fail git bisect terms --term-good skip &&
test_must_fail git bisect terms --term-good reset &&
test_path_is_missing .git/BISECT_TERMS
'
test_expect_success 'bisect start --term-* does store terms' '
git bisect reset &&
git bisect start --term-bad=one --term-good=two &&
git bisect terms >actual &&
cat <<-EOF >expected &&
Your current terms are two for the old state
and one for the new state.
EOF
test_cmp expected actual &&
git bisect terms --term-bad >actual &&
echo one >expected &&
test_cmp expected actual &&
git bisect terms --term-good >actual &&
echo two >expected &&
test_cmp expected actual
'
test_expect_success 'bisect start takes options and revs in any order' '
git bisect reset &&
git bisect start --term-good one $HASH4 \
--term-good two --term-bad bad-term \
$HASH1 --term-good three -- &&
(git bisect terms --term-bad && git bisect terms --term-good) >actual &&
printf "%s\n%s\n" bad-term three >expected &&
test_cmp expected actual
'
# Bisect is started with --term-new and --term-old arguments,
# then skip. The HEAD should be changed.
test_expect_success 'bisect skip works with --term*' '
git bisect reset &&
git bisect start --term-new=fixed --term-old=unfixed HEAD $HASH1 &&
hash_skipped_from=$(git rev-parse --verify HEAD) &&
git bisect skip &&
hash_skipped_to=$(git rev-parse --verify HEAD) &&
test "$hash_skipped_from" != "$hash_skipped_to"
'
test_expect_success 'git bisect reset cleans bisection state properly' '
git bisect reset &&
git bisect start &&
git bisect good $HASH1 &&
git bisect bad $HASH4 &&
git bisect reset &&
test -z "$(git for-each-ref "refs/bisect/*")" &&
test_path_is_missing ".git/BISECT_EXPECTED_REV" &&
test_path_is_missing ".git/BISECT_ANCESTORS_OK" &&
test_path_is_missing ".git/BISECT_LOG" &&
test_path_is_missing ".git/BISECT_RUN" &&
test_path_is_missing ".git/BISECT_TERMS" &&
test_path_is_missing ".git/head-name" &&
test_path_is_missing ".git/BISECT_HEAD" &&
test_path_is_missing ".git/BISECT_START"
'
test_expect_success 'bisect handles annotated tags' '
test_commit commit-one &&
git tag -m foo tag-one &&
test_commit commit-two &&
git tag -m foo tag-two &&
git bisect start &&
git bisect good tag-one &&
git bisect bad tag-two >output &&
bad=$(git rev-parse --verify tag-two^{commit}) &&
grep "$bad is the first bad commit" output
'
test_done