2007-03-23 08:49:59 +01:00
|
|
|
#!/bin/sh
|
|
|
|
#
|
|
|
|
# Copyright (c) 2007 Christian Couder
|
|
|
|
#
|
2008-09-03 10:59:29 +02:00
|
|
|
test_description='Tests git bisect functionality'
|
2007-03-23 08:49:59 +01:00
|
|
|
|
2007-04-06 08:27:44 +02:00
|
|
|
exec </dev/null
|
|
|
|
|
2020-11-19 00:44:36 +01:00
|
|
|
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-19 00:44:19 +01:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
2007-03-23 08:49:59 +01:00
|
|
|
. ./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
|
|
|
|
|
2007-04-24 07:10:47 +02:00
|
|
|
test_tick
|
2008-09-03 10:59:29 +02:00
|
|
|
git commit --quiet -m "$MSG" $_file
|
2007-03-23 08:49:59 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
HASH1=
|
2007-04-24 07:10:47 +02:00
|
|
|
HASH2=
|
2007-03-23 08:49:59 +01:00
|
|
|
HASH3=
|
|
|
|
HASH4=
|
|
|
|
|
2007-04-24 07:10:47 +02:00
|
|
|
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) &&
|
2007-03-23 08:49:59 +01:00
|
|
|
add_line_into_file "2: A new day for git" hello &&
|
2007-04-24 07:10:47 +02:00
|
|
|
HASH2=$(git rev-parse --verify HEAD) &&
|
2007-03-23 08:49:59 +01:00
|
|
|
add_line_into_file "3: Another new day for git" hello &&
|
2007-04-24 07:10:47 +02:00
|
|
|
HASH3=$(git rev-parse --verify HEAD) &&
|
2007-03-23 08:49:59 +01:00
|
|
|
add_line_into_file "4: Ciao for now" hello &&
|
2007-04-24 07:10:47 +02:00
|
|
|
HASH4=$(git rev-parse --verify HEAD)
|
|
|
|
'
|
2007-03-23 08:49:59 +01:00
|
|
|
|
2007-04-06 08:27:44 +02:00
|
|
|
test_expect_success 'bisect starts with only one bad' '
|
2007-04-06 07:52:37 +02:00
|
|
|
git bisect reset &&
|
|
|
|
git bisect start &&
|
2007-04-06 08:27:44 +02:00
|
|
|
git bisect bad $HASH4 &&
|
|
|
|
git bisect next
|
2007-04-06 07:52:37 +02:00
|
|
|
'
|
|
|
|
|
2007-04-17 06:51:48 +02:00
|
|
|
test_expect_success 'bisect does not start with only one good' '
|
2007-04-06 07:52:37 +02:00
|
|
|
git bisect reset &&
|
|
|
|
git bisect start &&
|
2015-03-20 11:13:05 +01:00
|
|
|
git bisect good $HASH1 &&
|
|
|
|
test_must_fail git bisect next
|
2007-04-06 07:52:37 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
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
|
|
|
|
'
|
|
|
|
|
git-bisect: make "start", "good" and "skip" succeed or fail atomically
Before this patch, when "git bisect start", "git bisect good" or
"git bisect skip" were called with many revisions, they could fail
after having already marked some revisions as "good", "bad" or
"skip".
This could be especilally bad for "git bisect start" because as
the file ".git/BISECT_NAMES" would not have been written, there
would have been no attempt to clear the marked revisions on a
"git bisect reset". That's because if there is no
".git/BISECT_NAMES" file, nothing is done to clean things up, as
the bisect session is not supposed to have started.
While at it, let's also create the ".git/BISECT_START" file, only
after ".git/BISECT_NAMES" as been created.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-14 05:41:45 +02:00
|
|
|
test_expect_success 'bisect fails if given any junk instead of revs' '
|
2008-04-12 07:53:59 +02:00
|
|
|
git bisect reset &&
|
git-bisect: make "start", "good" and "skip" succeed or fail atomically
Before this patch, when "git bisect start", "git bisect good" or
"git bisect skip" were called with many revisions, they could fail
after having already marked some revisions as "good", "bad" or
"skip".
This could be especilally bad for "git bisect start" because as
the file ".git/BISECT_NAMES" would not have been written, there
would have been no attempt to clear the marked revisions on a
"git bisect reset". That's because if there is no
".git/BISECT_NAMES" file, nothing is done to clean things up, as
the bisect session is not supposed to have started.
While at it, let's also create the ".git/BISECT_START" file, only
after ".git/BISECT_NAMES" as been created.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-14 05:41:45 +02:00
|
|
|
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/*")" &&
|
2008-07-27 06:53:30 +02:00
|
|
|
test -z "$(ls .git/BISECT_* 2>/dev/null)" &&
|
2008-04-12 07:53:59 +02:00
|
|
|
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 &&
|
git-bisect: make "start", "good" and "skip" succeed or fail atomically
Before this patch, when "git bisect start", "git bisect good" or
"git bisect skip" were called with many revisions, they could fail
after having already marked some revisions as "good", "bad" or
"skip".
This could be especilally bad for "git bisect start" because as
the file ".git/BISECT_NAMES" would not have been written, there
would have been no attempt to clear the marked revisions on a
"git bisect reset". That's because if there is no
".git/BISECT_NAMES" file, nothing is done to clean things up, as
the bisect session is not supposed to have started.
While at it, let's also create the ".git/BISECT_START" file, only
after ".git/BISECT_NAMES" as been created.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-14 05:41:45 +02:00
|
|
|
test -z "$(git for-each-ref "refs/bisect/*")" &&
|
2008-04-12 07:53:59 +02:00
|
|
|
git bisect good $HASH1 &&
|
|
|
|
git bisect bad $HASH4
|
2007-04-06 07:52:37 +02:00
|
|
|
'
|
|
|
|
|
2020-09-25 15:01:28 +02:00
|
|
|
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"
|
|
|
|
'
|
|
|
|
|
2020-11-19 00:44:36 +01:00
|
|
|
test_expect_success 'bisect reset: back in the main branch' '
|
2007-11-20 06:39:53 +01:00
|
|
|
git bisect reset &&
|
2020-11-19 00:44:36 +01:00
|
|
|
echo "* main" > branch.expect &&
|
2007-11-20 06:39:53 +01:00
|
|
|
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 &&
|
2020-11-19 00:44:36 +01:00
|
|
|
echo " main" > branch.expect &&
|
2007-11-20 06:39:53 +01:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2007-11-15 08:18:07 +01:00
|
|
|
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")"
|
|
|
|
'
|
|
|
|
|
2011-08-04 14:01:02 +02:00
|
|
|
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")"
|
|
|
|
'
|
|
|
|
|
2008-05-23 00:38:46 +02:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2011-08-04 14:00:57 +02:00
|
|
|
test_expect_success 'bisect start: no ".git/BISECT_START" created if junk rev' '
|
|
|
|
git bisect reset &&
|
2008-05-23 00:38:46 +02:00
|
|
|
test_must_fail git bisect start $HASH4 foo -- &&
|
|
|
|
git branch > branch.output &&
|
|
|
|
grep "* other" branch.output > /dev/null &&
|
2020-04-20 10:54:39 +02:00
|
|
|
test_path_is_missing .git/BISECT_START
|
2008-05-23 00:38:46 +02:00
|
|
|
'
|
|
|
|
|
2011-08-04 14:00:57 +02:00
|
|
|
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 &&
|
2013-03-23 04:52:44 +01:00
|
|
|
test_i18ngrep "* (no branch, bisect started on other)" branch.output > /dev/null &&
|
2011-08-04 14:00:57 +02:00
|
|
|
test_cmp saved .git/BISECT_START
|
|
|
|
'
|
2008-05-23 00:39:22 +02:00
|
|
|
test_expect_success 'bisect start: no ".git/BISECT_START" if mistaken rev' '
|
2008-05-23 00:38:46 +02:00
|
|
|
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 &&
|
2020-04-20 10:54:39 +02:00
|
|
|
test_path_is_missing .git/BISECT_START
|
2008-05-23 00:38:46 +02:00
|
|
|
'
|
|
|
|
|
2008-05-23 00:39:22 +02:00
|
|
|
test_expect_success 'bisect start: no ".git/BISECT_START" if checkout error' '
|
2008-05-23 00:38:46 +02:00
|
|
|
echo "temp stuff" > hello &&
|
|
|
|
test_must_fail git bisect start $HASH4 $HASH1 -- &&
|
|
|
|
git branch &&
|
|
|
|
git branch > branch.output &&
|
|
|
|
grep "* other" branch.output > /dev/null &&
|
2020-04-20 10:54:39 +02:00
|
|
|
test_path_is_missing .git/BISECT_START &&
|
2008-05-23 00:39:22 +02:00
|
|
|
test -z "$(git for-each-ref "refs/bisect/*")" &&
|
|
|
|
git checkout HEAD hello
|
2008-05-23 00:38:46 +02:00
|
|
|
'
|
|
|
|
|
2007-10-22 07:48:36 +02:00
|
|
|
# $HASH1 is good, $HASH4 is bad, we skip $HASH3
|
|
|
|
# but $HASH2 is bad,
|
|
|
|
# so we should find $HASH2 as the first bad commit
|
2013-04-12 00:36:10 +02:00
|
|
|
test_expect_success 'bisect skip: successful result' '
|
2015-03-20 11:13:05 +01:00
|
|
|
test_when_finished git bisect reset &&
|
2007-10-22 07:48:36 +02:00
|
|
|
git bisect reset &&
|
|
|
|
git bisect start $HASH4 $HASH1 &&
|
|
|
|
git bisect skip &&
|
|
|
|
git bisect bad > my_bisect_log.txt &&
|
2015-03-20 11:13:05 +01:00
|
|
|
grep "$HASH2 is the first bad commit" my_bisect_log.txt
|
2007-10-22 07:48:36 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
# $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' '
|
2015-03-20 11:13:05 +01:00
|
|
|
test_when_finished git bisect reset &&
|
2007-10-22 07:48:36 +02:00
|
|
|
git bisect start $HASH4 $HASH1 &&
|
2015-03-20 11:13:05 +01:00
|
|
|
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
|
2007-10-22 07:48:36 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
# $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' '
|
2015-03-20 11:13:05 +01:00
|
|
|
test_when_finished git bisect reset &&
|
2007-10-22 07:48:36 +02:00
|
|
|
git bisect start $HASH4 $HASH1 &&
|
2015-03-20 11:13:05 +01:00
|
|
|
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
|
2007-10-22 07:48:36 +02:00
|
|
|
'
|
|
|
|
|
2009-02-27 07:31:22 +01:00
|
|
|
# $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' '
|
2015-03-20 11:13:05 +01:00
|
|
|
test_when_finished git bisect reset &&
|
2009-02-27 07:31:22 +01:00
|
|
|
git bisect start &&
|
|
|
|
git bisect skip &&
|
|
|
|
git bisect bad &&
|
|
|
|
git bisect good $HASH1 &&
|
|
|
|
git bisect skip &&
|
2015-03-20 11:13:05 +01:00
|
|
|
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
|
2007-10-22 07:48:36 +02:00
|
|
|
'
|
|
|
|
|
2007-03-23 08:49:59 +01:00
|
|
|
# We want to automatically find the commit that
|
2020-08-07 23:58:34 +02:00
|
|
|
# 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
|
|
|
|
'
|
2007-04-04 07:12:02 +02:00
|
|
|
|
|
|
|
# We want to automatically find the commit that
|
2020-08-07 23:58:34 +02:00
|
|
|
# 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
|
|
|
|
'
|
2007-03-23 08:49:59 +01:00
|
|
|
|
2022-01-18 13:46:24 +01:00
|
|
|
test_expect_success 'bisect run accepts exit code 126 as bad' '
|
|
|
|
test_when_finished "git bisect reset" &&
|
|
|
|
write_script test_script.sh <<-\EOF &&
|
|
|
|
! grep Another hello || exit 126 >/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
|
|
|
|
'
|
|
|
|
|
bisect--helper: double-check run command on exit code 126 and 127
When a run command cannot be executed or found, shells return exit code
126 or 127, respectively. Valid run commands are allowed to return
these codes as well to indicate bad revisions, though, for historical
reasons. This means typos can cause bogus bisect runs that go over the
full distance and end up reporting invalid results.
The best solution would be to reserve exit codes 126 and 127, like
71b0251cdd (Bisect run: "skip" current commit if script exit code is
125., 2007-10-26) did for 125, and abort bisect run when we get them.
That might be inconvenient for those who relied on the documentation
stating that 126 and 127 can be used for bad revisions, though.
The workaround used by this patch is to run the command on a known-good
revision and abort if we still get the same error code. This adds one
step to runs with scripts that use exit codes 126 and 127, but keeps
them supported, with one exception: It won't work with commands that
cannot recognize the (manually marked) known-good revision as such.
Run commands that use low exit codes are unaffected. Typos are reported
after executing the missing command twice and three checkouts (the first
step, the known good revision and back to the revision of the first
step).
Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 13:46:32 +01:00
|
|
|
test_expect_success POSIXPERM 'bisect run fails with non-executable test script' '
|
2022-01-18 13:46:24 +01:00
|
|
|
test_when_finished "git bisect reset" &&
|
|
|
|
>not-executable.sh &&
|
|
|
|
chmod -x not-executable.sh &&
|
|
|
|
git bisect start &&
|
|
|
|
git bisect good $HASH1 &&
|
|
|
|
git bisect bad $HASH4 &&
|
|
|
|
test_must_fail git bisect run ./not-executable.sh >my_bisect_log.txt &&
|
|
|
|
! grep "is the first bad commit" my_bisect_log.txt
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'bisect run accepts exit code 127 as bad' '
|
|
|
|
test_when_finished "git bisect reset" &&
|
|
|
|
write_script test_script.sh <<-\EOF &&
|
|
|
|
! grep Another hello || exit 127 >/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
|
|
|
|
'
|
|
|
|
|
bisect--helper: double-check run command on exit code 126 and 127
When a run command cannot be executed or found, shells return exit code
126 or 127, respectively. Valid run commands are allowed to return
these codes as well to indicate bad revisions, though, for historical
reasons. This means typos can cause bogus bisect runs that go over the
full distance and end up reporting invalid results.
The best solution would be to reserve exit codes 126 and 127, like
71b0251cdd (Bisect run: "skip" current commit if script exit code is
125., 2007-10-26) did for 125, and abort bisect run when we get them.
That might be inconvenient for those who relied on the documentation
stating that 126 and 127 can be used for bad revisions, though.
The workaround used by this patch is to run the command on a known-good
revision and abort if we still get the same error code. This adds one
step to runs with scripts that use exit codes 126 and 127, but keeps
them supported, with one exception: It won't work with commands that
cannot recognize the (manually marked) known-good revision as such.
Run commands that use low exit codes are unaffected. Typos are reported
after executing the missing command twice and three checkouts (the first
step, the known good revision and back to the revision of the first
step).
Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 13:46:32 +01:00
|
|
|
test_expect_success 'bisect run fails with missing test script' '
|
2022-01-18 13:46:24 +01:00
|
|
|
test_when_finished "git bisect reset" &&
|
|
|
|
rm -f does-not-exist.sh &&
|
|
|
|
git bisect start &&
|
|
|
|
git bisect good $HASH1 &&
|
|
|
|
git bisect bad $HASH4 &&
|
|
|
|
test_must_fail git bisect run ./does-not-exist.sh >my_bisect_log.txt &&
|
|
|
|
! grep "is the first bad commit" my_bisect_log.txt
|
|
|
|
'
|
|
|
|
|
2007-10-22 07:48:36 +02:00
|
|
|
# $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 &&
|
2009-08-26 10:38:50 +02:00
|
|
|
grep "$HASH5 is the first bad commit" my_bisect_log.txt &&
|
2007-11-20 06:39:53 +01:00
|
|
|
git bisect log > log_to_replay.txt &&
|
2007-10-22 07:49:39 +02:00
|
|
|
git bisect reset
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'bisect skip and bisect replay' '
|
|
|
|
git bisect replay log_to_replay.txt > my_bisect_log.txt &&
|
2009-08-26 10:38:50 +02:00
|
|
|
grep "$HASH5 is the first bad commit" my_bisect_log.txt &&
|
2007-10-22 07:48:36 +02:00
|
|
|
git bisect reset
|
|
|
|
'
|
|
|
|
|
2007-10-26 05:39:37 +02:00
|
|
|
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) &&
|
2020-08-07 23:58:34 +02:00
|
|
|
write_script test_script.sh <<-\EOF &&
|
|
|
|
sed -ne \$p hello | grep Ciao >/dev/null && exit 125
|
|
|
|
! grep line hello >/dev/null
|
|
|
|
EOF
|
2007-10-26 05:39:37 +02:00
|
|
|
git bisect start $HASH6 $HASH1 &&
|
2020-08-07 23:58:34 +02:00
|
|
|
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
|
2007-10-26 05:39:37 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
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) &&
|
2020-08-07 23:58:34 +02:00
|
|
|
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
|
2007-10-26 05:39:37 +02:00
|
|
|
git bisect start $HASH7 $HASH1 &&
|
2020-08-07 23:58:34 +02:00
|
|
|
git bisect run ./test_script.sh >my_bisect_log.txt &&
|
2009-08-26 10:38:50 +02:00
|
|
|
grep "$HASH6 is the first bad commit" my_bisect_log.txt
|
2007-10-26 05:39:37 +02:00
|
|
|
'
|
|
|
|
|
2008-12-02 14:53:47 +01:00
|
|
|
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
|
|
|
|
'
|
2008-02-10 14:59:50 +01:00
|
|
|
|
2008-12-02 14:53:47 +01:00
|
|
|
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' '
|
2008-02-10 14:59:50 +01:00
|
|
|
git bisect reset &&
|
2020-11-19 00:44:36 +01:00
|
|
|
git checkout main^ &&
|
2008-02-10 14:59:50 +01:00
|
|
|
HEAD=$(git rev-parse --verify HEAD) &&
|
|
|
|
git bisect start &&
|
2008-02-24 02:14:17 +01:00
|
|
|
test $HEAD = $(cat .git/BISECT_START) &&
|
2008-02-10 14:59:50 +01:00
|
|
|
git bisect reset &&
|
|
|
|
test $HEAD = $(git rev-parse --verify HEAD)
|
2008-05-05 09:43:00 +02:00
|
|
|
'
|
|
|
|
|
2008-05-07 23:54:28 +02:00
|
|
|
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 &&
|
2016-06-17 22:21:12 +02:00
|
|
|
test_i18ngrep "mistook good and bad" rev_list_error &&
|
2008-05-07 23:54:28 +02:00
|
|
|
git bisect reset
|
|
|
|
'
|
|
|
|
|
2008-05-23 01:28:57 +02:00
|
|
|
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 &&
|
2009-08-26 10:38:50 +02:00
|
|
|
grep "$HASH7 is the first bad commit" my_bisect_log.txt &&
|
2008-05-23 01:28:57 +02:00
|
|
|
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 05:52:22 +02: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 &&
|
2016-06-17 22:21:12 +02:00
|
|
|
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 05:52:22 +02:00
|
|
|
grep $HASH4 my_bisect_log.txt &&
|
|
|
|
git bisect good > my_bisect_log.txt &&
|
2017-01-03 20:57:07 +01:00
|
|
|
! 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 05:52:22 +02: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 &&
|
2016-06-17 22:21:12 +02:00
|
|
|
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 05:52:22 +02:00
|
|
|
grep $HASH4 my_bisect_log.txt &&
|
|
|
|
git bisect skip > my_bisect_log.txt 2>&1 &&
|
2010-01-03 17:20:30 +01:00
|
|
|
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 05:52:22 +02: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 &&
|
2016-06-17 22:21:12 +02:00
|
|
|
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 05:52:22 +02:00
|
|
|
grep $HASH4 my_bisect_log.txt &&
|
|
|
|
test_must_fail git bisect bad > my_bisect_log.txt 2>&1 &&
|
2016-06-17 22:21:12 +02:00
|
|
|
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 05:52:22 +02: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 &&
|
2012-04-11 13:24:01 +02:00
|
|
|
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 05:52:22 +02:00
|
|
|
grep "$HASH5" merge_bases.txt &&
|
|
|
|
grep "$SIDE_HASH5" merge_bases.txt
|
|
|
|
'
|
|
|
|
|
2020-08-07 23:58:37 +02:00
|
|
|
# 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 05:52:22 +02:00
|
|
|
test_expect_success 'good merge bases when good and bad are siblings' '
|
|
|
|
git bisect start "$B_HASH" "$A_HASH" > my_bisect_log.txt &&
|
2016-06-17 22:21:12 +02:00
|
|
|
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 05:52:22 +02:00
|
|
|
git bisect good > my_bisect_log2.txt &&
|
2016-06-17 22:21:12 +02:00
|
|
|
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 05:52:22 +02: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
|
|
|
|
'
|
|
|
|
|
2008-08-22 05:52:29 +02:00
|
|
|
test_expect_success 'optimized merge base checks' '
|
|
|
|
git bisect start "$HASH7" "$SIDE_HASH7" > my_bisect_log.txt &&
|
2016-06-17 22:21:12 +02:00
|
|
|
test_i18ngrep "merge base must be tested" my_bisect_log.txt &&
|
2008-08-22 05:52:29 +02:00
|
|
|
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) &&
|
2019-12-18 19:12:12 +01:00
|
|
|
git bisect bad &&
|
2008-08-22 05:52:29 +02:00
|
|
|
git bisect good "$A_HASH" > my_bisect_log4.txt &&
|
2016-06-17 22:21:12 +02:00
|
|
|
test_i18ngrep "merge base must be tested" my_bisect_log4.txt &&
|
2020-04-20 10:54:39 +02:00
|
|
|
test_path_is_missing ".git/BISECT_ANCESTORS_OK"
|
2008-08-22 05:52:29 +02:00
|
|
|
'
|
|
|
|
|
2009-03-29 11:45:01 +02:00
|
|
|
# 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 &&
|
2010-10-31 02:46:54 +01:00
|
|
|
PARA_HASH3=$(git rev-parse --verify HEAD) &&
|
2009-03-29 11:45:01 +02:00
|
|
|
git merge -m "merge HASH4 and PARA_HASH3" "$HASH4" &&
|
2010-10-31 02:46:54 +01:00
|
|
|
PARA_HASH4=$(git rev-parse --verify HEAD) &&
|
2009-03-29 11:45:01 +02:00
|
|
|
add_line_into_file "5(para): add line on parallel branch" dir1/file1 &&
|
2010-10-31 02:46:54 +01:00
|
|
|
PARA_HASH5=$(git rev-parse --verify HEAD) &&
|
2009-03-29 11:45:01 +02:00
|
|
|
add_line_into_file "6(para): add line on parallel branch" dir2/file2 &&
|
2010-10-31 02:46:54 +01:00
|
|
|
PARA_HASH6=$(git rev-parse --verify HEAD) &&
|
2009-03-29 11:45:01 +02:00
|
|
|
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 &&
|
2009-08-26 10:38:50 +02:00
|
|
|
grep "$PARA_HASH1 is the first bad commit" my_bisect_log.txt
|
2009-03-29 11:45:01 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
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 &&
|
2009-08-26 10:38:50 +02:00
|
|
|
grep "$PARA_HASH4 is the first bad commit" my_bisect_log.txt
|
2009-03-29 11:45:01 +02:00
|
|
|
'
|
|
|
|
|
2009-06-06 06:41:35 +02:00
|
|
|
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 &&
|
2009-06-13 07:21:06 +02:00
|
|
|
para3=$(git rev-parse --verify HEAD) &&
|
|
|
|
test "$para3" = "$PARA_HASH3"
|
2009-06-06 06:41:35 +02:00
|
|
|
'
|
|
|
|
|
2021-02-23 22:11:32 +01:00
|
|
|
test_expect_success 'erroring out when using bad path arguments' '
|
2010-02-28 23:19:09 +01:00
|
|
|
test_must_fail git bisect start $PARA_HASH7 $HASH1 -- foobar 2> error.txt &&
|
2021-02-23 22:11:32 +01:00
|
|
|
test_i18ngrep "bad path arguments" error.txt
|
2010-02-28 23:19:09 +01:00
|
|
|
'
|
|
|
|
|
2011-08-09 04:11:54 +02:00
|
|
|
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" \
|
2015-03-20 11:13:05 +01:00
|
|
|
>../nocheckout.log
|
2011-08-09 04:11:54 +02:00
|
|
|
) &&
|
|
|
|
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" \
|
2015-03-20 11:13:05 +01:00
|
|
|
>../defaulted.log
|
2011-08-09 04:11:54 +02:00
|
|
|
) &&
|
|
|
|
grep "$HASH3 is the first bad commit" defaulted.log
|
|
|
|
'
|
|
|
|
|
2007-03-23 08:49:59 +01:00
|
|
|
#
|
2011-08-04 14:00:59 +02:00
|
|
|
# This creates a broken branch which cannot be checked out because
|
|
|
|
# the tree created has been deleted.
|
2007-03-23 08:49:59 +01:00
|
|
|
#
|
2011-08-04 14:00:59 +02:00
|
|
|
# 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 &&
|
2015-03-20 11:13:05 +01:00
|
|
|
git commit -m "6(broken): Added file that will be deleted" &&
|
2011-08-04 14:00:59 +02:00
|
|
|
git tag BROKEN_HASH6 &&
|
2019-06-29 00:59:23 +02:00
|
|
|
deleted=$(git rev-parse --verify HEAD:missing) &&
|
2011-08-04 14:00:59 +02:00
|
|
|
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 &&
|
2015-03-20 11:13:05 +01:00
|
|
|
git commit -m "9(broken): Remove missing file" &&
|
2011-08-04 14:00:59 +02:00
|
|
|
git tag BROKEN_HASH9 &&
|
2019-06-29 00:59:23 +02:00
|
|
|
rm .git/objects/$(test_oid_to_path $deleted)
|
2011-08-04 14:00:59 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
echo "" > expected.ok
|
|
|
|
cat > expected.missing-tree.default <<EOF
|
2019-06-29 00:59:23 +02:00
|
|
|
fatal: unable to read tree $deleted
|
2011-08-04 14:00:59 +02:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2011-08-04 14:01:02 +02:00
|
|
|
check_same()
|
|
|
|
{
|
|
|
|
echo "Checking $1 is the same as $2" &&
|
2012-12-21 20:10:10 +01:00
|
|
|
test_cmp_rev "$1" "$2"
|
2011-08-04 14:01:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
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 07:23:28 +01:00
|
|
|
test_must_fail git bisect good BISECT_HEAD &&
|
2011-08-04 14:01:02 +02:00
|
|
|
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 07:23:28 +01:00
|
|
|
test_must_fail git bisect good BISECT_HEAD &&
|
2011-08-04 14:01:02 +02:00
|
|
|
check_same BROKEN_HASH9 bisect/bad &&
|
|
|
|
git bisect reset
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'bisect: demonstrate identification of damage boundary' "
|
|
|
|
git bisect reset &&
|
|
|
|
git checkout broken &&
|
2020-11-19 00:44:36 +01:00
|
|
|
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 07:23:28 +01:00
|
|
|
test_must_fail git bisect run \"\$SHELL_PATH\" -c '
|
2011-08-04 14:01:02 +02:00
|
|
|
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
|
|
|
|
"
|
|
|
|
|
2013-04-13 17:22:57 +02:00
|
|
|
cat > expected.bisect-log <<EOF
|
2019-06-29 00:59:23 +02:00
|
|
|
# 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>.
|
2013-04-13 17:22:57 +02:00
|
|
|
EOF
|
|
|
|
|
2016-08-09 10:53:38 +02:00
|
|
|
test_expect_success 'bisect log: successful result' '
|
2013-04-13 17:22:57 +02:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2013-04-22 23:02:29 +02:00
|
|
|
cat > expected.bisect-skip-log <<EOF
|
2019-06-29 00:59:23 +02:00
|
|
|
# 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
|
2013-04-22 23:02:29 +02:00
|
|
|
# only skipped commits left to test
|
2019-06-29 00:59:23 +02:00
|
|
|
# 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>.
|
2013-04-22 23:02:29 +02:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2014-12-25 19:25:33 +01:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2015-06-29 17:40:33 +02: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
|
|
|
|
'
|
|
|
|
|
2020-05-07 23:29:40 +02:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2015-06-29 17:40:33 +02: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
|
|
|
|
'
|
|
|
|
|
2015-06-29 17:40:34 +02:00
|
|
|
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 &&
|
2019-01-02 16:38:35 +01:00
|
|
|
echo "error: no terms defined" >expected &&
|
2021-02-11 02:53:53 +01:00
|
|
|
test_cmp expected actual
|
2015-06-29 17:40:34 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2015-06-29 17:40:35 +02:00
|
|
|
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 &&
|
2020-05-21 01:26:27 +02:00
|
|
|
test_must_fail git bisect start --term-good &&
|
2015-06-29 17:40:35 +02:00
|
|
|
test_must_fail git bisect start --term-good invalid..term &&
|
2020-05-21 01:26:27 +02:00
|
|
|
test_must_fail git bisect start --term-bad &&
|
2015-06-29 17:40:35 +02:00
|
|
|
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
|
2021-02-11 02:53:53 +01:00
|
|
|
test_cmp expected actual &&
|
2015-06-29 17:40:35 +02:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2021-04-29 22:15:15 +02:00
|
|
|
# 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"
|
|
|
|
'
|
|
|
|
|
2017-09-29 08:49:39 +02:00
|
|
|
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/*")" &&
|
2020-12-18 16:14:06 +01:00
|
|
|
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"
|
2017-09-29 08:49:39 +02:00
|
|
|
'
|
|
|
|
|
2021-03-16 16:15:55 +01:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2021-09-13 19:38:59 +02:00
|
|
|
test_expect_success 'bisect run fails with exit code equals or greater than 128' '
|
|
|
|
write_script test_script.sh <<-\EOF &&
|
|
|
|
exit 128
|
|
|
|
EOF
|
|
|
|
test_must_fail git bisect run ./test_script.sh &&
|
|
|
|
write_script test_script.sh <<-\EOF &&
|
|
|
|
exit 255
|
|
|
|
EOF
|
|
|
|
test_must_fail git bisect run ./test_script.sh
|
|
|
|
'
|
|
|
|
|
2021-09-13 19:39:00 +02:00
|
|
|
test_expect_success 'bisect visualize with a filename with dash and space' '
|
|
|
|
echo "My test line" >>"./-hello 2" &&
|
|
|
|
git add -- "./-hello 2" &&
|
|
|
|
git commit --quiet -m "Add test line" -- "./-hello 2" &&
|
|
|
|
git bisect visualize -p -- "-hello 2"
|
|
|
|
'
|
|
|
|
|
bisect: output state before we are ready to compute bisection
Commit 73c6de06aff8 ("bisect: don't use invalid oid as rev when
starting") changes the behaviour of `git bisect` to consider invalid
oids as pathspecs again, as in the old shell implementation.
While that behaviour may be desirable, it can also cause confusion. For
example, while bisecting in a particular repo I encountered this:
$ git bisect start d93ff48803f0 v6.3
$
...which led to me sitting for a few moments, wondering why there's no
printout stating the first rev to check.
It turns out that the tag was actually "6.3", not "v6.3", and thus the
bisect was still silently started with only a bad rev, because
d93ff48803f0 was a valid oid and "v6.3" was silently considered to be a
pathspec.
While this behaviour may be desirable, it can be confusing, especially
with different repo conventions either using or not using "v" before
release names, or when a branch name or tag is simply misspelled on the
command line.
In order to avoid situations like this, make it more clear what we're
waiting for:
$ git bisect start d93ff48803f0 v6.3
status: waiting for good commit(s), bad commit known
We already have good output once the bisect process has begun in
earnest, so we don't need to do anything more there.
Signed-off-by: Chris Down <chris@chrisdown.name>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-11 20:00:09 +02:00
|
|
|
test_expect_success 'bisect state output with multiple good commits' '
|
|
|
|
git bisect reset &&
|
|
|
|
git bisect start >output &&
|
|
|
|
grep "waiting for both good and bad commits" output &&
|
2022-05-11 20:00:14 +02:00
|
|
|
git bisect log >output &&
|
|
|
|
grep "waiting for both good and bad commits" output &&
|
bisect: output state before we are ready to compute bisection
Commit 73c6de06aff8 ("bisect: don't use invalid oid as rev when
starting") changes the behaviour of `git bisect` to consider invalid
oids as pathspecs again, as in the old shell implementation.
While that behaviour may be desirable, it can also cause confusion. For
example, while bisecting in a particular repo I encountered this:
$ git bisect start d93ff48803f0 v6.3
$
...which led to me sitting for a few moments, wondering why there's no
printout stating the first rev to check.
It turns out that the tag was actually "6.3", not "v6.3", and thus the
bisect was still silently started with only a bad rev, because
d93ff48803f0 was a valid oid and "v6.3" was silently considered to be a
pathspec.
While this behaviour may be desirable, it can be confusing, especially
with different repo conventions either using or not using "v" before
release names, or when a branch name or tag is simply misspelled on the
command line.
In order to avoid situations like this, make it more clear what we're
waiting for:
$ git bisect start d93ff48803f0 v6.3
status: waiting for good commit(s), bad commit known
We already have good output once the bisect process has begun in
earnest, so we don't need to do anything more there.
Signed-off-by: Chris Down <chris@chrisdown.name>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-11 20:00:09 +02:00
|
|
|
git bisect good "$HASH1" >output &&
|
|
|
|
grep "waiting for bad commit, 1 good commit known" output &&
|
2022-05-11 20:00:14 +02:00
|
|
|
git bisect log >output &&
|
|
|
|
grep "waiting for bad commit, 1 good commit known" output &&
|
bisect: output state before we are ready to compute bisection
Commit 73c6de06aff8 ("bisect: don't use invalid oid as rev when
starting") changes the behaviour of `git bisect` to consider invalid
oids as pathspecs again, as in the old shell implementation.
While that behaviour may be desirable, it can also cause confusion. For
example, while bisecting in a particular repo I encountered this:
$ git bisect start d93ff48803f0 v6.3
$
...which led to me sitting for a few moments, wondering why there's no
printout stating the first rev to check.
It turns out that the tag was actually "6.3", not "v6.3", and thus the
bisect was still silently started with only a bad rev, because
d93ff48803f0 was a valid oid and "v6.3" was silently considered to be a
pathspec.
While this behaviour may be desirable, it can be confusing, especially
with different repo conventions either using or not using "v" before
release names, or when a branch name or tag is simply misspelled on the
command line.
In order to avoid situations like this, make it more clear what we're
waiting for:
$ git bisect start d93ff48803f0 v6.3
status: waiting for good commit(s), bad commit known
We already have good output once the bisect process has begun in
earnest, so we don't need to do anything more there.
Signed-off-by: Chris Down <chris@chrisdown.name>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-11 20:00:09 +02:00
|
|
|
git bisect good "$HASH2" >output &&
|
2022-05-11 20:00:14 +02:00
|
|
|
grep "waiting for bad commit, 2 good commits known" output &&
|
|
|
|
git bisect log >output &&
|
bisect: output state before we are ready to compute bisection
Commit 73c6de06aff8 ("bisect: don't use invalid oid as rev when
starting") changes the behaviour of `git bisect` to consider invalid
oids as pathspecs again, as in the old shell implementation.
While that behaviour may be desirable, it can also cause confusion. For
example, while bisecting in a particular repo I encountered this:
$ git bisect start d93ff48803f0 v6.3
$
...which led to me sitting for a few moments, wondering why there's no
printout stating the first rev to check.
It turns out that the tag was actually "6.3", not "v6.3", and thus the
bisect was still silently started with only a bad rev, because
d93ff48803f0 was a valid oid and "v6.3" was silently considered to be a
pathspec.
While this behaviour may be desirable, it can be confusing, especially
with different repo conventions either using or not using "v" before
release names, or when a branch name or tag is simply misspelled on the
command line.
In order to avoid situations like this, make it more clear what we're
waiting for:
$ git bisect start d93ff48803f0 v6.3
status: waiting for good commit(s), bad commit known
We already have good output once the bisect process has begun in
earnest, so we don't need to do anything more there.
Signed-off-by: Chris Down <chris@chrisdown.name>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-11 20:00:09 +02:00
|
|
|
grep "waiting for bad commit, 2 good commits known" output
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'bisect state output with bad commit' '
|
|
|
|
git bisect reset &&
|
|
|
|
git bisect start >output &&
|
|
|
|
grep "waiting for both good and bad commits" output &&
|
2022-05-11 20:00:14 +02:00
|
|
|
git bisect log >output &&
|
|
|
|
grep "waiting for both good and bad commits" output &&
|
bisect: output state before we are ready to compute bisection
Commit 73c6de06aff8 ("bisect: don't use invalid oid as rev when
starting") changes the behaviour of `git bisect` to consider invalid
oids as pathspecs again, as in the old shell implementation.
While that behaviour may be desirable, it can also cause confusion. For
example, while bisecting in a particular repo I encountered this:
$ git bisect start d93ff48803f0 v6.3
$
...which led to me sitting for a few moments, wondering why there's no
printout stating the first rev to check.
It turns out that the tag was actually "6.3", not "v6.3", and thus the
bisect was still silently started with only a bad rev, because
d93ff48803f0 was a valid oid and "v6.3" was silently considered to be a
pathspec.
While this behaviour may be desirable, it can be confusing, especially
with different repo conventions either using or not using "v" before
release names, or when a branch name or tag is simply misspelled on the
command line.
In order to avoid situations like this, make it more clear what we're
waiting for:
$ git bisect start d93ff48803f0 v6.3
status: waiting for good commit(s), bad commit known
We already have good output once the bisect process has begun in
earnest, so we don't need to do anything more there.
Signed-off-by: Chris Down <chris@chrisdown.name>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-11 20:00:09 +02:00
|
|
|
git bisect bad "$HASH4" >output &&
|
2022-05-11 20:00:14 +02:00
|
|
|
grep -F "waiting for good commit(s), bad commit known" output &&
|
|
|
|
git bisect log >output &&
|
bisect: output state before we are ready to compute bisection
Commit 73c6de06aff8 ("bisect: don't use invalid oid as rev when
starting") changes the behaviour of `git bisect` to consider invalid
oids as pathspecs again, as in the old shell implementation.
While that behaviour may be desirable, it can also cause confusion. For
example, while bisecting in a particular repo I encountered this:
$ git bisect start d93ff48803f0 v6.3
$
...which led to me sitting for a few moments, wondering why there's no
printout stating the first rev to check.
It turns out that the tag was actually "6.3", not "v6.3", and thus the
bisect was still silently started with only a bad rev, because
d93ff48803f0 was a valid oid and "v6.3" was silently considered to be a
pathspec.
While this behaviour may be desirable, it can be confusing, especially
with different repo conventions either using or not using "v" before
release names, or when a branch name or tag is simply misspelled on the
command line.
In order to avoid situations like this, make it more clear what we're
waiting for:
$ git bisect start d93ff48803f0 v6.3
status: waiting for good commit(s), bad commit known
We already have good output once the bisect process has begun in
earnest, so we don't need to do anything more there.
Signed-off-by: Chris Down <chris@chrisdown.name>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-11 20:00:09 +02:00
|
|
|
grep -F "waiting for good commit(s), bad commit known" output
|
|
|
|
'
|
|
|
|
|
2007-03-23 08:49:59 +01:00
|
|
|
test_done
|