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

616 lines
14 KiB

[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
#!/bin/sh
USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]'
LONG_USAGE='git bisect help
print this long help message.
git bisect start [<bad> [<good>...]] [--] [<pathspec>...]
reset bisect state and start bisection.
git bisect bad [<rev>]
mark <rev> a known-bad revision.
git bisect good [<rev>...]
mark <rev>... known-good revisions.
git bisect skip [(<rev>|<range>)...]
mark <rev>... untestable revisions.
git bisect next
find next bisection to test and check it out.
git bisect reset [<branch>]
finish bisection search and go back to branch.
git bisect visualize
show bisect status in gitk.
git bisect replay <logfile>
replay bisection log.
git bisect log
show bisect log.
git bisect run <cmd>...
use <cmd>... to automatically bisect.
Please use "git help bisect" to get the full man page.'
OPTIONS_SPEC=
. git-sh-setup
require_work_tree
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
sq() {
@@PERL@@ -e '
for (@ARGV) {
s/'\''/'\'\\\\\'\''/g;
print " '\''$_'\''";
}
print "\n";
' "$@"
}
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
bisect_autostart() {
test -s "$GIT_DIR/BISECT_START" || {
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
echo >&2 'You need to start by "git bisect start"'
if test -t 0
then
echo >&2 -n 'Do you want me to do it for you [Y/n]? '
read yesno
case "$yesno" in
[Nn]*)
exit ;;
esac
bisect_start
else
exit 1
fi
}
}
bisect_start() {
#
# Verify HEAD.
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
#
head=$(GIT_DIR="$GIT_DIR" git symbolic-ref -q HEAD) ||
head=$(GIT_DIR="$GIT_DIR" git rev-parse --verify HEAD) ||
die "Bad HEAD - I need a HEAD"
#
# Check if we are bisecting.
#
start_head=''
if test -s "$GIT_DIR/BISECT_START"
then
# Reset to the rev from where we started.
start_head=$(cat "$GIT_DIR/BISECT_START")
git checkout "$start_head" || exit
else
# Get rev from where we start.
case "$head" in
refs/heads/*|$_x40)
# This error message should only be triggered by
# cogito usage, and cogito users should understand
# it relates to cg-seek.
[ -s "$GIT_DIR/head-name" ] &&
die "won't bisect on seeked tree"
start_head="${head#refs/heads/}"
;;
*)
die "Bad HEAD - strange symbolic ref"
;;
esac
fi
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
#
# Get rid of any old bisect state.
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
#
bisect_clean_state || exit
#
# Check for one bad and then some good revisions.
#
has_double_dash=0
for arg; do
case "$arg" in --) has_double_dash=1; break ;; esac
done
orig_args=$(sq "$@")
bad_seen=0
eval=''
while [ $# -gt 0 ]; do
arg="$1"
case "$arg" in
--)
shift
break
;;
*)
rev=$(git rev-parse -q --verify "$arg^{commit}") || {
test $has_double_dash -eq 1 &&
die "'$arg' does not appear to be a valid revision"
break
}
case $bad_seen in
0) state='bad' ; bad_seen=1 ;;
*) state='good' ;;
esac
eval="$eval bisect_write '$state' '$rev' 'nolog'; "
shift
;;
esac
done
#
# Change state.
# In case of mistaken revs or checkout error, or signals received,
# "bisect_auto_next" below may exit or misbehave.
# We have to trap this to be able to clean up using
# "bisect_clean_state".
#
trap 'bisect_clean_state' 0
trap 'exit 255' 1 2 3 15
#
# Write new start state.
#
echo "$start_head" >"$GIT_DIR/BISECT_START" &&
sq "$@" >"$GIT_DIR/BISECT_NAMES" &&
eval "$eval" &&
echo "git bisect start$orig_args" >>"$GIT_DIR/BISECT_LOG" || exit
#
# Check if we can proceed to the next bisect state.
#
bisect_auto_next
trap '-' 0
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
}
bisect_write() {
state="$1"
rev="$2"
nolog="$3"
case "$state" in
bad) tag="$state" ;;
good|skip) tag="$state"-"$rev" ;;
*) die "Bad bisect_write argument: $state" ;;
esac
git update-ref "refs/bisect/$tag" "$rev" || exit
echo "# $state: $(git show-branch $rev)" >>"$GIT_DIR/BISECT_LOG"
test -n "$nolog" || echo "git bisect $state $rev" >>"$GIT_DIR/BISECT_LOG"
}
is_expected_rev() {
test -f "$GIT_DIR/BISECT_EXPECTED_REV" &&
test "$1" = $(cat "$GIT_DIR/BISECT_EXPECTED_REV")
}
mark_expected_rev() {
echo "$1" > "$GIT_DIR/BISECT_EXPECTED_REV"
}
check_expected_revs() {
for _rev in "$@"; do
if ! is_expected_rev "$_rev"; then
rm -f "$GIT_DIR/BISECT_ANCESTORS_OK"
rm -f "$GIT_DIR/BISECT_EXPECTED_REV"
return
fi
done
}
bisect_skip() {
all=''
for arg in "$@"
do
case "$arg" in
*..*)
revs=$(git rev-list "$arg") || die "Bad rev input: $arg" ;;
*)
revs=$(sq "$arg") ;;
esac
all="$all $revs"
done
eval bisect_state 'skip' $all
}
bisect_state() {
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
bisect_autostart
state=$1
case "$#,$state" in
0,*)
die "Please call 'bisect_state' with at least one argument." ;;
1,bad|1,good|1,skip)
rev=$(git rev-parse --verify HEAD) ||
die "Bad rev input: HEAD"
bisect_write "$state" "$rev"
check_expected_revs "$rev" ;;
2,bad|*,good|*,skip)
shift
eval=''
for rev in "$@"
do
sha=$(git rev-parse --verify "$rev^{commit}") ||
die "Bad rev input: $rev"
eval="$eval bisect_write '$state' '$sha'; "
done
eval "$eval"
check_expected_revs "$@" ;;
*,bad)
die "'git bisect bad' can take only one argument." ;;
*)
usage ;;
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
esac
bisect_auto_next
}
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
bisect_next_check() {
missing_good= missing_bad=
git show-ref -q --verify refs/bisect/bad || missing_bad=t
test -n "$(git for-each-ref "refs/bisect/good-*")" || missing_good=t
case "$missing_good,$missing_bad,$1" in
,,*)
: have both good and bad - ok
;;
*,)
# do not have both but not asked to fail - just report.
false
;;
t,,good)
# have bad but not good. we could bisect although
# this is less optimum.
echo >&2 'Warning: bisecting only with a bad commit.'
if test -t 0
then
printf >&2 'Are you sure [Y/n]? '
read yesno
case "$yesno" in [Nn]*) exit 1 ;; esac
fi
: bisect without good...
;;
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
*)
THEN=''
test -s "$GIT_DIR/BISECT_START" || {
echo >&2 'You need to start by "git bisect start".'
THEN='then '
}
echo >&2 'You '$THEN'need to give me at least one good' \
'and one bad revisions.'
echo >&2 '(You can use "git bisect bad" and' \
'"git bisect good" for that.)'
exit 1 ;;
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
esac
}
bisect_auto_next() {
bisect_next_check && bisect_next || :
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
}
eval_and_string_together() {
_eval="$1"
eval "$_eval" | {
while read line
do
echo "$line &&"
done
echo ':'
}
}
exit_if_skipped_commits () {
_tried=$1
_bad=$2
if test -n "$_tried" ; then
echo "There are only 'skip'ped commit left to test."
echo "The first bad commit could be any of:"
echo "$_tried" | tr '[|]' '[\012]'
test -n "$_bad" && echo "$_bad"
echo "We cannot bisect more!"
exit 2
fi
}
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>
17 years ago
bisect_checkout() {
_rev="$1"
_msg="$2"
echo "Bisecting: $_msg"
mark_expected_rev "$_rev"
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>
17 years ago
git checkout -q "$_rev" || exit
git show-branch "$_rev"
}
is_among() {
_rev="$1"
_list="$2"
case "$_list" in *$_rev*) return 0 ;; esac
return 1
}
handle_bad_merge_base() {
_badmb="$1"
_good="$2"
if is_expected_rev "$_badmb"; then
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>
17 years ago
cat >&2 <<EOF
The merge base $_badmb is bad.
This means the bug has been fixed between $_badmb and [$_good].
EOF
exit 3
else
cat >&2 <<EOF
Some good revs are not ancestor of the bad rev.
git bisect cannot work properly in this case.
Maybe you mistake good and bad revs?
EOF
exit 1
fi
}
handle_skipped_merge_base() {
_mb="$1"
_bad="$2"
_good="$3"
cat >&2 <<EOF
Warning: the merge base between $_bad and [$_good] must be skipped.
So we cannot be sure the first bad commit is between $_mb and $_bad.
We continue anyway.
EOF
}
#
# "check_merge_bases" checks that merge bases are not "bad".
#
# - If one is "good", that's good, we have nothing to do.
# - If one is "bad", it means the user assumed something wrong
# and we must exit.
# - If one is "skipped", we can't know but we should warn.
# - If we don't know, we should check it out and ask the user to test.
#
# In the last case we will return 1, and otherwise 0.
#
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>
17 years ago
check_merge_bases() {
_bad="$1"
_good="$2"
_skip="$3"
for _mb in $(git merge-base --all $_bad $_good)
do
if is_among "$_mb" "$_good"; then
continue
elif test "$_mb" = "$_bad"; then
handle_bad_merge_base "$_bad" "$_good"
elif is_among "$_mb" "$_skip"; then
handle_skipped_merge_base "$_mb" "$_bad" "$_good"
else
bisect_checkout "$_mb" "a merge base must be tested"
return 1
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>
17 years ago
fi
done
return 0
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>
17 years ago
}
#
# "check_good_are_ancestors_of_bad" checks that all "good" revs are
# ancestor of the "bad" rev.
#
# If that's not the case, we need to check the merge bases.
# If a merge base must be tested by the user we return 1 and
# otherwise 0.
#
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>
17 years ago
check_good_are_ancestors_of_bad() {
test -f "$GIT_DIR/BISECT_ANCESTORS_OK" &&
return
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>
17 years ago
_bad="$1"
_good=$(echo $2 | sed -e 's/\^//g')
_skip="$3"
# Bisecting with no good rev is ok
test -z "$_good" && return
_side=$(git rev-list $_good ^$_bad)
if test -n "$_side"; then
# Return if a checkout was done
check_merge_bases "$_bad" "$_good" "$_skip" || return
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>
17 years ago
fi
: > "$GIT_DIR/BISECT_ANCESTORS_OK"
return 0
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>
17 years ago
}
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
bisect_next() {
case "$#" in 0) ;; *) usage ;; esac
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
bisect_autostart
bisect_next_check good
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>
17 years ago
# Get bad, good and skipped revs
bad=$(git rev-parse --verify refs/bisect/bad) &&
good=$(git for-each-ref --format='^%(objectname)' \
"refs/bisect/good-*" | tr '\012' ' ') &&
skip=$(git for-each-ref --format='%(objectname)' \
"refs/bisect/skip-*" | tr '\012' ' ') || exit
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>
17 years ago
# Maybe some merge bases must be tested first
check_good_are_ancestors_of_bad "$bad" "$good" "$skip"
# Return now if a checkout has already been done
test "$?" -eq "1" && return
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>
17 years ago
# Get bisection information
eval="git bisect--helper --next-vars" &&
eval=$(eval_and_string_together "$eval") &&
eval "$eval" || exit
if [ -z "$bisect_rev" ]; then
# We should exit here only if the "bad"
# commit is also a "skip" commit (see above).
exit_if_skipped_commits "$bisect_tried"
echo "$bad was both good and bad"
exit 1
fi
if [ "$bisect_rev" = "$bad" ]; then
exit_if_skipped_commits "$bisect_tried" "$bad"
echo "$bisect_rev is first bad commit"
git diff-tree --pretty $bisect_rev
exit 0
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
fi
rev-list: estimate number of bisection step left This patch teaches "git rev-list --bisect-vars" to output an estimate of the number of bisection step left _after the current one_ along with the other variables it already outputs. This patch also makes "git-bisect.sh" display this number of steps left _after the current one_, along with the estimate of the number of revisions left to test (after the current one). Here is a table to help analyse what should be the best estimate for the number of bisect steps left. N : linear case --> probabilities --> best ------------------------------------------------------------- 1 : G-B --> 0 --> 0 2 : G-U1-B --> 0 --> 0 3 : G-U1-U2-B --> 0(1/3) 1(2/3) --> 1 4 : G-U1-U2-U3-B --> 1 --> 1 5 : G-U1-U2-U3-U4-B --> 1(3/5) 2(2/5) --> 1 6 : G-U1-U2-U3-U4-U5-B --> 1(2/6) 2(4/6) --> 2 7 : G-U1-U2-U3-U4-U5-U6-B --> 1(1/7) 2(6/7) --> 2 8 : G-U1-U2-U3-U4-U5-U6-U7-B --> 2 --> 2 9 : G-U1-U2-U3-U4-U5-U6-U7-U8-B --> 2(7/9) 3(2/9) --> 2 10: G-U1-U2-U3-U4-U5-U6-U7-U8-U9-B --> 2(6/10)3(4/10)--> 2 In the column "N", there is the number of revisions that could _now_ be the first bad commit we are looking for. The "linear case" column describes the linear history corresponding to the number in column N. G means good, B means bad, and Ux means unknown. Note that the first bad revision we are looking for can be any Ux or B. In the "probabilities" column, there are the different outcomes in number of steps with the odds of each outcome in parenthesis corresponding to the linear case. The "best" column gives the most accurate estimate among the different outcomes in the "probabilities" column. We have the following: best(2^n) == n - 1 and for any x between 0 included and 2^n excluded, the probability for n - 1 steps left looks like: P(2^n + x) == (2^n - x) / (2^n + x) and P(2^n + x) < 0.5 means 2^n < 3x So the algorithm used in this patch calculates 2^n and x, and then choose between returning n - 1 and n. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
bisect_checkout "$bisect_rev" "$bisect_nr revisions left to test after this (roughly $bisect_steps steps)"
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
}
bisect_visualize() {
bisect_next_check fail
if test $# = 0
then
case "${DISPLAY+set}${SESSIONNAME+set}${MSYSTEM+set}${SECURITYSESSIONID+set}" in
'') set git log ;;
set*) set gitk ;;
esac
else
case "$1" in
git*|tig) ;;
-*) set git log "$@" ;;
*) set git "$@" ;;
esac
fi
not=$(git for-each-ref --format='%(refname)' "refs/bisect/good-*")
eval '"$@"' refs/bisect/bad --not $not -- $(cat "$GIT_DIR/BISECT_NAMES")
}
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
bisect_reset() {
test -s "$GIT_DIR/BISECT_START" || {
echo "We are not bisecting."
return
}
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
case "$#" in
0) branch=$(cat "$GIT_DIR/BISECT_START") ;;
1) git show-ref --verify --quiet -- "refs/heads/$1" ||
die "$1 does not seem to be a valid branch"
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
branch="$1" ;;
*)
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
usage ;;
esac
git checkout "$branch" && bisect_clean_state
}
bisect_clean_state() {
# There may be some refs packed during bisection.
git for-each-ref --format='%(refname) %(objectname)' refs/bisect/\* |
while read ref hash
do
git update-ref -d $ref $hash || exit
done
rm -f "$GIT_DIR/BISECT_EXPECTED_REV" &&
rm -f "$GIT_DIR/BISECT_ANCESTORS_OK" &&
rm -f "$GIT_DIR/BISECT_LOG" &&
rm -f "$GIT_DIR/BISECT_NAMES" &&
rm -f "$GIT_DIR/BISECT_RUN" &&
# Cleanup head-name if it got left by an old version of git-bisect
rm -f "$GIT_DIR/head-name" &&
rm -f "$GIT_DIR/BISECT_START"
}
bisect_replay () {
test -r "$1" || die "cannot read $1 for replaying"
bisect_reset
while read git bisect command rev
do
test "$git $bisect" = "git bisect" -o "$git" = "git-bisect" || continue
if test "$git" = "git-bisect"; then
rev="$command"
command="$bisect"
fi
case "$command" in
start)
cmd="bisect_start $rev"
eval "$cmd" ;;
good|bad|skip)
bisect_write "$command" "$rev" ;;
*)
die "?? what are you talking about?" ;;
esac
done <"$1"
bisect_auto_next
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
}
bisect_run () {
bisect_next_check fail
while true
do
echo "running $@"
"$@"
res=$?
# Check for really bad run error.
if [ $res -lt 0 -o $res -ge 128 ]; then
echo >&2 "bisect run failed:"
echo >&2 "exit code $res from '$@' is < 0 or >= 128"
exit $res
fi
# Find current state depending on run success or failure.
# A special exit code of 125 means cannot test.
if [ $res -eq 125 ]; then
state='skip'
elif [ $res -gt 0 ]; then
state='bad'
else
state='good'
fi
# We have to use a subshell because "bisect_state" can exit.
( bisect_state $state > "$GIT_DIR/BISECT_RUN" )
res=$?
cat "$GIT_DIR/BISECT_RUN"
if grep "first bad commit could be any of" "$GIT_DIR/BISECT_RUN" \
> /dev/null; then
echo >&2 "bisect run cannot continue any more"
exit $res
fi
if [ $res -ne 0 ]; then
echo >&2 "bisect run failed:"
echo >&2 "'bisect_state $state' exited with error code $res"
exit $res
fi
if grep "is first bad commit" "$GIT_DIR/BISECT_RUN" > /dev/null; then
echo "bisect run success"
exit 0;
fi
done
}
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
case "$#" in
0)
usage ;;
*)
cmd="$1"
shift
case "$cmd" in
help)
git bisect -h ;;
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
start)
bisect_start "$@" ;;
bad|good)
bisect_state "$cmd" "$@" ;;
skip)
bisect_skip "$@" ;;
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
next)
# Not sure we want "next" at the UI level anymore.
bisect_next "$@" ;;
visualize|view)
bisect_visualize "$@" ;;
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
reset)
bisect_reset "$@" ;;
replay)
bisect_replay "$@" ;;
log)
cat "$GIT_DIR/BISECT_LOG" ;;
run)
bisect_run "$@" ;;
[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
*)
usage ;;
esac
esac