git/git-bisect.sh

450 lines
9.7 KiB
Bash
Raw Normal View History

[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>
2005-07-31 01:08:20 +08:00
#!/bin/sh
USAGE='[start|bad|good|next|reset|visualize|replay|log|run]'
LONG_USAGE='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 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 skip [<rev>...]
mark <rev>... untestable revisions.
git bisect run <cmd>...
use <cmd>... to automatically bisect.'
. 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>
2005-07-31 01:08:20 +08:00
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>
2005-07-31 01:08:20 +08:00
bisect_autostart() {
test -d "$GIT_DIR/refs/bisect" || {
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. If we were bisecting before this, reset to the
# top-of-line master first!
#
head=$(GIT_DIR="$GIT_DIR" git symbolic-ref HEAD) ||
die "Bad HEAD - I need a symbolic ref"
[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>
2005-07-31 01:08:20 +08:00
case "$head" in
refs/heads/bisect)
if [ -s "$GIT_DIR/head-name" ]; then
branch=`cat "$GIT_DIR/head-name"`
else
branch=master
fi
git checkout $branch || exit
[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>
2005-07-31 01:08:20 +08:00
;;
refs/heads/*)
[ -s "$GIT_DIR/head-name" ] && die "won't bisect on seeked tree"
echo "$head" | sed 's#^refs/heads/##' >"$GIT_DIR/head-name"
[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>
2005-07-31 01:08:20 +08:00
;;
*)
die "Bad HEAD - strange symbolic ref"
[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>
2005-07-31 01:08:20 +08:00
;;
esac
#
# Get rid of any old bisect state
#
bisect_clean_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>
2005-07-31 01:08:20 +08:00
mkdir "$GIT_DIR/refs/bisect"
#
# 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
while [ $# -gt 0 ]; do
arg="$1"
case "$arg" in
--)
shift
break
;;
*)
rev=$(git rev-parse --verify "$arg^{commit}" 2>/dev/null) || {
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
bisect_write "$state" "$rev" 'nolog'
shift
;;
esac
done
sq "$@" >"$GIT_DIR/BISECT_NAMES"
echo "git-bisect start$orig_args" >>"$GIT_DIR/BISECT_LOG"
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>
2005-07-31 01:08:20 +08:00
}
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
echo "$rev" >"$GIT_DIR/refs/bisect/$tag"
echo "# $state: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
test -z "$nolog" && echo "git-bisect $state $rev" >>"$GIT_DIR/BISECT_LOG"
}
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>
2005-07-31 01:08:20 +08:00
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" ;;
2,bad)
rev=$(git rev-parse --verify "$2^{commit}") ||
die "Bad rev input: $2"
bisect_write "$state" "$rev" ;;
*,good|*,skip)
shift
revs=$(git rev-parse --revs-only --no-flags "$@") &&
test '' != "$revs" || die "Bad rev input: $@"
for rev in $revs
do
rev=$(git rev-parse --verify "$rev^{commit}") ||
die "Bad rev commit: $rev^{commit}"
bisect_write "$state" "$rev"
done ;;
*)
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>
2005-07-31 01:08:20 +08:00
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>
2005-07-31 01:08:20 +08:00
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]? '
case "$(read 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>
2005-07-31 01:08:20 +08:00
*)
THEN=''
test -d "$GIT_DIR/refs/bisect" || {
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>
2005-07-31 01:08:20 +08:00
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>
2005-07-31 01:08:20 +08:00
}
filter_skipped() {
_eval="$1"
_skip="$2"
if [ -z "$_skip" ]; then
eval $_eval
return
fi
# Let's parse the output of:
# "git rev-list --bisect-vars --bisect-all ..."
eval $_eval | while read hash line
do
case "$VARS,$FOUND,$TRIED,$hash" in
# We display some vars.
1,*,*,*) echo "$hash $line" ;;
# Split line.
,*,*,---*) ;;
# We had nothing to search.
,,,bisect_rev*)
echo "bisect_rev="
VARS=1
;;
# We did not find a good bisect rev.
# This should happen only if the "bad"
# commit is also a "skip" commit.
,,*,bisect_rev*)
echo "bisect_rev=$TRIED"
VARS=1
;;
# We are searching.
,,*,*)
TRIED="${TRIED:+$TRIED|}$hash"
case "$_skip" in
*$hash*) ;;
*)
echo "bisect_rev=$hash"
echo "bisect_tried=\"$TRIED\""
FOUND=1
;;
esac
;;
# We have already found a rev to be tested.
,1,*,bisect_rev*) VARS=1 ;;
,1,*,*) ;;
# ???
*) die "filter_skipped error " \
"VARS: '$VARS' " \
"FOUND: '$FOUND' " \
"TRIED: '$TRIED' " \
"hash: '$hash' " \
"line: '$line'"
;;
esac
done
}
exit_if_skipped_commits () {
_tried=$1
if expr "$_tried" : ".*[|].*" > /dev/null ; then
echo "There are only 'skip'ped commit left to test."
echo "The first bad commit could be any of:"
echo "$_tried" | sed -e 's/[|]/\n/g'
echo "We cannot bisect more!"
exit 2
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>
2005-07-31 01:08:20 +08:00
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>
2005-07-31 01:08:20 +08:00
bisect_autostart
bisect_next_check good
skip=$(git for-each-ref --format='%(objectname)' \
"refs/bisect/skip-*" | tr '[\012]' ' ') || exit
BISECT_OPT=''
test -n "$skip" && BISECT_OPT='--bisect-all'
bad=$(git rev-parse --verify refs/bisect/bad) &&
good=$(git for-each-ref --format='^%(objectname)' \
"refs/bisect/good-*" | tr '[\012]' ' ') &&
eval="git rev-list --bisect-vars $BISECT_OPT $good $bad --" &&
eval="$eval $(cat "$GIT_DIR/BISECT_NAMES")" &&
eval=$(filter_skipped "$eval" "$skip") &&
eval "$eval" || exit
if [ -z "$bisect_rev" ]; then
echo "$bad was both good and bad"
exit 1
fi
if [ "$bisect_rev" = "$bad" ]; then
exit_if_skipped_commits "$bisect_tried"
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>
2005-07-31 01:08:20 +08:00
fi
# We should exit here only if the "bad"
# commit is also a "skip" commit (see above).
exit_if_skipped_commits "$bisect_rev"
echo "Bisecting: $bisect_nr revisions left to test after this"
echo "$bisect_rev" >"$GIT_DIR/refs/heads/new-bisect"
git checkout -q new-bisect || exit
[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>
2005-07-31 01:08:20 +08:00
mv "$GIT_DIR/refs/heads/new-bisect" "$GIT_DIR/refs/heads/bisect" &&
GIT_DIR="$GIT_DIR" git symbolic-ref HEAD refs/heads/bisect
git show-branch "$bisect_rev"
[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>
2005-07-31 01:08:20 +08:00
}
bisect_visualize() {
bisect_next_check fail
not=`cd "$GIT_DIR/refs" && echo bisect/good-*`
eval gitk 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>
2005-07-31 01:08:20 +08:00
bisect_reset() {
case "$#" in
0) if [ -s "$GIT_DIR/head-name" ]; then
branch=`cat "$GIT_DIR/head-name"`
else
branch=master
fi ;;
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>
2005-07-31 01:08:20 +08:00
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>
2005-07-31 01:08:20 +08:00
usage ;;
esac
if git checkout "$branch"; then
rm -f "$GIT_DIR/head-name"
bisect_clean_state
fi
}
bisect_clean_state() {
rm -fr "$GIT_DIR/refs/bisect"
rm -f "$GIT_DIR/refs/heads/bisect"
rm -f "$GIT_DIR/BISECT_LOG"
rm -f "$GIT_DIR/BISECT_NAMES"
rm -f "$GIT_DIR/BISECT_RUN"
}
bisect_replay () {
test -r "$1" || die "cannot read $1 for replaying"
bisect_reset
while read bisect command rev
do
test "$bisect" = "git-bisect" || continue
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>
2005-07-31 01:08:20 +08:00
}
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.
if [ $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 [ $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>
2005-07-31 01:08:20 +08:00
case "$#" in
0)
usage ;;
*)
cmd="$1"
shift
case "$cmd" in
start)
bisect_start "$@" ;;
bad|good|skip)
bisect_state "$cmd" "$@" ;;
[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>
2005-07-31 01:08:20 +08:00
next)
# Not sure we want "next" at the UI level anymore.
bisect_next "$@" ;;
visualize)
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>
2005-07-31 01:08:20 +08:00
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>
2005-07-31 01:08:20 +08:00
*)
usage ;;
esac
esac