[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-30 21:08:20 +04:00
|
|
|
#!/bin/sh
|
2005-12-11 12:55:49 +03:00
|
|
|
|
2008-04-11 07:55:21 +04:00
|
|
|
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>...]
|
2007-04-04 09:12:02 +04:00
|
|
|
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.
|
2007-10-29 07:31:52 +03:00
|
|
|
git bisect skip [<rev>...]
|
|
|
|
mark <rev>... untestable revisions.
|
2007-04-04 09:12:02 +04:00
|
|
|
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>...
|
2008-04-11 07:55:21 +04:00
|
|
|
use <cmd>... to automatically bisect.
|
|
|
|
|
|
|
|
Please use "git help bisect" to get the full man page.'
|
2005-12-11 12:55:49 +03:00
|
|
|
|
2007-11-06 12:50:02 +03:00
|
|
|
OPTIONS_SPEC=
|
2005-11-24 11:12:11 +03:00
|
|
|
. git-sh-setup
|
2007-02-06 01:03:27 +03:00
|
|
|
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-30 21:08:20 +04:00
|
|
|
|
2008-02-10 16:59:50 +03:00
|
|
|
_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"
|
|
|
|
|
2005-11-28 04:42:05 +03:00
|
|
|
sq() {
|
2006-07-08 19:32:04 +04:00
|
|
|
@@PERL@@ -e '
|
2005-11-28 04:42:05 +03:00
|
|
|
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-30 21:08:20 +04:00
|
|
|
bisect_autostart() {
|
2008-05-28 20:57:02 +04:00
|
|
|
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>
2005-07-30 21:08:20 +04:00
|
|
|
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() {
|
|
|
|
#
|
2008-05-23 03:28:57 +04:00
|
|
|
# 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>
2005-07-30 21:08:20 +04:00
|
|
|
#
|
2008-04-16 06:09:49 +04:00
|
|
|
head=$(GIT_DIR="$GIT_DIR" git symbolic-ref -q HEAD) ||
|
2008-02-10 16:59:50 +03:00
|
|
|
head=$(GIT_DIR="$GIT_DIR" git rev-parse --verify HEAD) ||
|
|
|
|
die "Bad HEAD - I need a HEAD"
|
2008-05-23 03:28:57 +04:00
|
|
|
|
2008-05-05 11:43:00 +04:00
|
|
|
#
|
2008-05-23 03:28:57 +04:00
|
|
|
# Check if we are bisecting.
|
2008-05-05 11:43:00 +04:00
|
|
|
#
|
git-bisect: make "start", "good" and "skip" succeed or fail atomically
Before this patch, when "git bisect start", "git bisect good" or
"git bisect skip" were called with many revisions, they could fail
after having already marked some revisions as "good", "bad" or
"skip".
This could be especilally bad for "git bisect start" because as
the file ".git/BISECT_NAMES" would not have been written, there
would have been no attempt to clear the marked revisions on a
"git bisect reset". That's because if there is no
".git/BISECT_NAMES" file, nothing is done to clean things up, as
the bisect session is not supposed to have started.
While at it, let's also create the ".git/BISECT_START" file, only
after ".git/BISECT_NAMES" as been created.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-14 07:41:45 +04:00
|
|
|
start_head=''
|
2008-05-23 03:28:57 +04:00
|
|
|
if test -s "$GIT_DIR/BISECT_START"
|
|
|
|
then
|
|
|
|
# Reset to the rev from where we started.
|
2008-05-23 02:38:59 +04:00
|
|
|
start_head=$(cat "$GIT_DIR/BISECT_START")
|
|
|
|
git checkout "$start_head" || exit
|
2008-05-23 03:28:57 +04:00
|
|
|
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>
2005-07-30 21:08:20 +04:00
|
|
|
|
|
|
|
#
|
2008-05-23 03:28:57 +04:00
|
|
|
# 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>
2005-07-30 21:08:20 +04:00
|
|
|
#
|
2008-05-28 20:57:02 +04:00
|
|
|
bisect_clean_state || exit
|
2007-04-04 09:12:02 +04:00
|
|
|
|
|
|
|
#
|
|
|
|
# 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
|
git-bisect: make "start", "good" and "skip" succeed or fail atomically
Before this patch, when "git bisect start", "git bisect good" or
"git bisect skip" were called with many revisions, they could fail
after having already marked some revisions as "good", "bad" or
"skip".
This could be especilally bad for "git bisect start" because as
the file ".git/BISECT_NAMES" would not have been written, there
would have been no attempt to clear the marked revisions on a
"git bisect reset". That's because if there is no
".git/BISECT_NAMES" file, nothing is done to clean things up, as
the bisect session is not supposed to have started.
While at it, let's also create the ".git/BISECT_START" file, only
after ".git/BISECT_NAMES" as been created.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-14 07:41:45 +04:00
|
|
|
eval=''
|
2007-04-04 09:12:02 +04:00
|
|
|
while [ $# -gt 0 ]; do
|
|
|
|
arg="$1"
|
|
|
|
case "$arg" in
|
|
|
|
--)
|
2007-10-22 09:48:23 +04:00
|
|
|
shift
|
2007-04-04 09:12:02 +04:00
|
|
|
break
|
|
|
|
;;
|
|
|
|
*)
|
2008-05-23 03:28:57 +04:00
|
|
|
rev=$(git rev-parse -q --verify "$arg^{commit}") || {
|
2007-04-04 09:12:02 +04:00
|
|
|
test $has_double_dash -eq 1 &&
|
|
|
|
die "'$arg' does not appear to be a valid revision"
|
|
|
|
break
|
|
|
|
}
|
2007-10-24 09:01:13 +04:00
|
|
|
case $bad_seen in
|
|
|
|
0) state='bad' ; bad_seen=1 ;;
|
|
|
|
*) state='good' ;;
|
|
|
|
esac
|
git-bisect: make "start", "good" and "skip" succeed or fail atomically
Before this patch, when "git bisect start", "git bisect good" or
"git bisect skip" were called with many revisions, they could fail
after having already marked some revisions as "good", "bad" or
"skip".
This could be especilally bad for "git bisect start" because as
the file ".git/BISECT_NAMES" would not have been written, there
would have been no attempt to clear the marked revisions on a
"git bisect reset". That's because if there is no
".git/BISECT_NAMES" file, nothing is done to clean things up, as
the bisect session is not supposed to have started.
While at it, let's also create the ".git/BISECT_START" file, only
after ".git/BISECT_NAMES" as been created.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-14 07:41:45 +04:00
|
|
|
eval="$eval bisect_write '$state' '$rev' 'nolog'; "
|
2007-10-22 09:48:23 +04:00
|
|
|
shift
|
2007-04-04 09:12:02 +04:00
|
|
|
;;
|
|
|
|
esac
|
2007-10-22 09:48:23 +04:00
|
|
|
done
|
2007-04-04 09:12:02 +04:00
|
|
|
|
2008-05-23 02:39:22 +04:00
|
|
|
#
|
|
|
|
# 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" &&
|
2008-05-28 20:57:02 +04:00
|
|
|
sq "$@" >"$GIT_DIR/BISECT_NAMES" &&
|
2008-05-23 02:39:22 +04:00
|
|
|
eval "$eval" &&
|
2008-07-11 20:01:29 +04:00
|
|
|
echo "git bisect start$orig_args" >>"$GIT_DIR/BISECT_LOG" || exit
|
2008-05-23 02:39:22 +04:00
|
|
|
#
|
|
|
|
# Check if we can proceed to the next bisect state.
|
|
|
|
#
|
2007-04-04 09:12:02 +04:00
|
|
|
bisect_auto_next
|
2008-05-23 02:39:22 +04:00
|
|
|
|
|
|
|
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>
2005-07-30 21:08:20 +04:00
|
|
|
}
|
|
|
|
|
2007-10-24 09:01:05 +04:00
|
|
|
bisect_write() {
|
|
|
|
state="$1"
|
|
|
|
rev="$2"
|
2007-10-24 09:01:13 +04:00
|
|
|
nolog="$3"
|
2007-10-24 09:01:05 +04:00
|
|
|
case "$state" in
|
|
|
|
bad) tag="$state" ;;
|
|
|
|
good|skip) tag="$state"-"$rev" ;;
|
|
|
|
*) die "Bad bisect_write argument: $state" ;;
|
|
|
|
esac
|
2008-05-23 02:39:22 +04:00
|
|
|
git update-ref "refs/bisect/$tag" "$rev" || exit
|
2008-02-12 22:50:57 +03:00
|
|
|
echo "# $state: $(git show-branch $rev)" >>"$GIT_DIR/BISECT_LOG"
|
2008-07-11 20:01:29 +04:00
|
|
|
test -n "$nolog" || echo "git bisect $state $rev" >>"$GIT_DIR/BISECT_LOG"
|
2007-10-24 09:01:05 +04:00
|
|
|
}
|
|
|
|
|
2008-08-22 07:52:29 +04:00
|
|
|
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
|
|
|
|
}
|
|
|
|
|
2007-10-24 09:01:21 +04:00
|
|
|
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-30 21:08:20 +04:00
|
|
|
bisect_autostart
|
2007-10-24 09:01:21 +04:00
|
|
|
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"
|
2008-08-22 07:52:29 +04:00
|
|
|
bisect_write "$state" "$rev"
|
|
|
|
check_expected_revs "$rev" ;;
|
2008-04-12 09:53:59 +04:00
|
|
|
2,bad|*,good|*,skip)
|
2007-10-24 09:01:21 +04:00
|
|
|
shift
|
git-bisect: make "start", "good" and "skip" succeed or fail atomically
Before this patch, when "git bisect start", "git bisect good" or
"git bisect skip" were called with many revisions, they could fail
after having already marked some revisions as "good", "bad" or
"skip".
This could be especilally bad for "git bisect start" because as
the file ".git/BISECT_NAMES" would not have been written, there
would have been no attempt to clear the marked revisions on a
"git bisect reset". That's because if there is no
".git/BISECT_NAMES" file, nothing is done to clean things up, as
the bisect session is not supposed to have started.
While at it, let's also create the ".git/BISECT_START" file, only
after ".git/BISECT_NAMES" as been created.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-14 07:41:45 +04:00
|
|
|
eval=''
|
2008-04-12 09:53:59 +04:00
|
|
|
for rev in "$@"
|
2007-10-24 09:01:21 +04:00
|
|
|
do
|
2008-04-12 13:17:36 +04:00
|
|
|
sha=$(git rev-parse --verify "$rev^{commit}") ||
|
2008-04-12 09:53:59 +04:00
|
|
|
die "Bad rev input: $rev"
|
git-bisect: make "start", "good" and "skip" succeed or fail atomically
Before this patch, when "git bisect start", "git bisect good" or
"git bisect skip" were called with many revisions, they could fail
after having already marked some revisions as "good", "bad" or
"skip".
This could be especilally bad for "git bisect start" because as
the file ".git/BISECT_NAMES" would not have been written, there
would have been no attempt to clear the marked revisions on a
"git bisect reset". That's because if there is no
".git/BISECT_NAMES" file, nothing is done to clean things up, as
the bisect session is not supposed to have started.
While at it, let's also create the ".git/BISECT_START" file, only
after ".git/BISECT_NAMES" as been created.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-14 07:41:45 +04:00
|
|
|
eval="$eval bisect_write '$state' '$sha'; "
|
|
|
|
done
|
2008-08-22 07:52:29 +04:00
|
|
|
eval "$eval"
|
|
|
|
check_expected_revs "$@" ;;
|
2008-04-12 09:53:59 +04:00
|
|
|
*,bad)
|
|
|
|
die "'git bisect bad' can take only one argument." ;;
|
2005-08-30 23:45:41 +04:00
|
|
|
*)
|
|
|
|
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-30 21:08:20 +04:00
|
|
|
esac
|
2007-10-22 09:48:36 +04:00
|
|
|
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-30 21:08:20 +04:00
|
|
|
bisect_next_check() {
|
2007-04-06 10:27:44 +04:00
|
|
|
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
|
2007-04-06 09:51:14 +04:00
|
|
|
|
2007-04-06 10:27:44 +04:00
|
|
|
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]? '
|
2008-08-11 21:37:46 +04:00
|
|
|
read yesno
|
|
|
|
case "$yesno" in [Nn]*) exit 1 ;; esac
|
2007-04-06 10:27:44 +04:00
|
|
|
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-30 21:08:20 +04:00
|
|
|
*)
|
2007-04-06 10:27:44 +04:00
|
|
|
THEN=''
|
2008-05-28 20:57:02 +04:00
|
|
|
test -s "$GIT_DIR/BISECT_START" || {
|
2007-04-06 10:27:44 +04:00
|
|
|
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-30 21:08:20 +04:00
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
|
|
|
bisect_auto_next() {
|
2005-09-18 00:51:03 +04:00
|
|
|
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-30 21:08:20 +04:00
|
|
|
}
|
|
|
|
|
2007-10-22 09:48:36 +04:00
|
|
|
filter_skipped() {
|
|
|
|
_eval="$1"
|
|
|
|
_skip="$2"
|
|
|
|
|
|
|
|
if [ -z "$_skip" ]; 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>
2008-08-22 07:52:22 +04:00
|
|
|
eval "$_eval"
|
2007-10-22 09:48:36 +04:00
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
|
|
|
# Let's parse the output of:
|
|
|
|
# "git rev-list --bisect-vars --bisect-all ..."
|
bisect: test merge base if good rev is not an ancestor of bad rev
Before this patch, "git bisect", when it was given some good revs that
are not ancestor of the bad rev, didn't check if the merge bases were
good. "git bisect" just supposed that the user knew what he was doing,
and that, when he said the revs were good, he knew that it meant that
all the revs in the history leading to the good revs were also
considered good.
But in pratice, the user may not know that a good rev is not an
ancestor of the bad rev, or he may not know/remember that all revs
leading to the good rev will be considered good. So he may give a good
rev that is a sibling, instead of an ancestor, of the bad rev, when in
fact there can be one rev becoming good in the branch of the good rev
(because the bug was already fixed there, for example) instead of one
rev becoming bad in the branch of the bad rev.
For example, if there is the following history:
A--B--C--D
\
E--F
and we launch "git bisect start D F" then only C and D would have been
considered as possible first bad commit before this patch. This could
invite user errors; F could be the commit that fixes the bug that exists
everywhere else.
The purpose of this patch is to detect when "git bisect" is passed
some good revs that are not ancestors of the bad rev, and then to first
ask the user to test the merge bases between the good and bad revs.
If the merge bases are good then all is fine, we can continue
bisecting. Otherwise, if one merge base is bad, it means that the
assumption that all revs leading to the good one are good too is
wrong and we error out. In the case where one merge base is skipped we
issue a warning and then continue bisecting anyway.
These checks will also catch the case where good and bad have been
mistaken. This means that we can remove the check that was done latter
on the output of "git rev-list --bisect-vars".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-22 07:52:22 +04:00
|
|
|
eval "$_eval" | while read hash line
|
2007-10-22 09:48:36 +04:00
|
|
|
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:"
|
2007-11-15 11:39:57 +03:00
|
|
|
echo "$_tried" | tr '[|]' '[\012]'
|
2007-10-22 09:48:36 +04:00
|
|
|
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>
2008-08-22 07:52:22 +04:00
|
|
|
bisect_checkout() {
|
|
|
|
_rev="$1"
|
|
|
|
_msg="$2"
|
|
|
|
echo "Bisecting: $_msg"
|
2008-08-22 07:52:29 +04:00
|
|
|
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>
2008-08-22 07:52:22 +04:00
|
|
|
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"
|
2008-08-22 07:52:29 +04:00
|
|
|
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>
2008-08-22 07:52:22 +04:00
|
|
|
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
|
|
|
|
}
|
|
|
|
|
2008-09-06 09:27:03 +04:00
|
|
|
#
|
|
|
|
# "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>
2008-08-22 07:52:22 +04:00
|
|
|
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"
|
2008-09-06 09:27:03 +04:00
|
|
|
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>
2008-08-22 07:52:22 +04:00
|
|
|
fi
|
|
|
|
done
|
2008-09-06 09:27:03 +04:00
|
|
|
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>
2008-08-22 07:52:22 +04:00
|
|
|
}
|
|
|
|
|
2008-09-06 09:27:03 +04:00
|
|
|
#
|
|
|
|
# "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>
2008-08-22 07:52:22 +04:00
|
|
|
check_good_are_ancestors_of_bad() {
|
2008-08-22 07:52:29 +04:00
|
|
|
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>
2008-08-22 07:52:22 +04:00
|
|
|
_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
|
2008-09-06 09:27:03 +04:00
|
|
|
# Return if a checkout was done
|
2008-08-22 07:52:29 +04:00
|
|
|
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>
2008-08-22 07:52:22 +04:00
|
|
|
fi
|
2008-08-22 07:52:29 +04:00
|
|
|
|
|
|
|
: > "$GIT_DIR/BISECT_ANCESTORS_OK"
|
2008-09-06 09:27:03 +04:00
|
|
|
|
|
|
|
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>
2008-08-22 07:52:22 +04:00
|
|
|
}
|
|
|
|
|
[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-30 21:08:20 +04:00
|
|
|
bisect_next() {
|
2007-10-22 09:48:23 +04:00
|
|
|
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-30 21:08:20 +04:00
|
|
|
bisect_autostart
|
2007-04-06 10:27:44 +04:00
|
|
|
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>
2008-08-22 07:52:22 +04:00
|
|
|
# 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' ' ') &&
|
2007-10-22 09:48:36 +04:00
|
|
|
skip=$(git for-each-ref --format='%(objectname)' \
|
bisect: test merge base if good rev is not an ancestor of bad rev
Before this patch, "git bisect", when it was given some good revs that
are not ancestor of the bad rev, didn't check if the merge bases were
good. "git bisect" just supposed that the user knew what he was doing,
and that, when he said the revs were good, he knew that it meant that
all the revs in the history leading to the good revs were also
considered good.
But in pratice, the user may not know that a good rev is not an
ancestor of the bad rev, or he may not know/remember that all revs
leading to the good rev will be considered good. So he may give a good
rev that is a sibling, instead of an ancestor, of the bad rev, when in
fact there can be one rev becoming good in the branch of the good rev
(because the bug was already fixed there, for example) instead of one
rev becoming bad in the branch of the bad rev.
For example, if there is the following history:
A--B--C--D
\
E--F
and we launch "git bisect start D F" then only C and D would have been
considered as possible first bad commit before this patch. This could
invite user errors; F could be the commit that fixes the bug that exists
everywhere else.
The purpose of this patch is to detect when "git bisect" is passed
some good revs that are not ancestors of the bad rev, and then to first
ask the user to test the merge bases between the good and bad revs.
If the merge bases are good then all is fine, we can continue
bisecting. Otherwise, if one merge base is bad, it means that the
assumption that all revs leading to the good one are good too is
wrong and we error out. In the case where one merge base is skipped we
issue a warning and then continue bisecting anyway.
These checks will also catch the case where good and bad have been
mistaken. This means that we can remove the check that was done latter
on the output of "git rev-list --bisect-vars".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-22 07:52:22 +04:00
|
|
|
"refs/bisect/skip-*" | tr '\012' ' ') &&
|
2007-10-22 09:48:36 +04:00
|
|
|
|
bisect: test merge base if good rev is not an ancestor of bad rev
Before this patch, "git bisect", when it was given some good revs that
are not ancestor of the bad rev, didn't check if the merge bases were
good. "git bisect" just supposed that the user knew what he was doing,
and that, when he said the revs were good, he knew that it meant that
all the revs in the history leading to the good revs were also
considered good.
But in pratice, the user may not know that a good rev is not an
ancestor of the bad rev, or he may not know/remember that all revs
leading to the good rev will be considered good. So he may give a good
rev that is a sibling, instead of an ancestor, of the bad rev, when in
fact there can be one rev becoming good in the branch of the good rev
(because the bug was already fixed there, for example) instead of one
rev becoming bad in the branch of the bad rev.
For example, if there is the following history:
A--B--C--D
\
E--F
and we launch "git bisect start D F" then only C and D would have been
considered as possible first bad commit before this patch. This could
invite user errors; F could be the commit that fixes the bug that exists
everywhere else.
The purpose of this patch is to detect when "git bisect" is passed
some good revs that are not ancestors of the bad rev, and then to first
ask the user to test the merge bases between the good and bad revs.
If the merge bases are good then all is fine, we can continue
bisecting. Otherwise, if one merge base is bad, it means that the
assumption that all revs leading to the good one are good too is
wrong and we error out. In the case where one merge base is skipped we
issue a warning and then continue bisecting anyway.
These checks will also catch the case where good and bad have been
mistaken. This means that we can remove the check that was done latter
on the output of "git rev-list --bisect-vars".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-22 07:52:22 +04:00
|
|
|
# Maybe some merge bases must be tested first
|
2008-09-06 09:27:03 +04:00
|
|
|
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>
2008-08-22 07:52:22 +04:00
|
|
|
|
|
|
|
# Get bisection information
|
2007-10-22 09:48:36 +04:00
|
|
|
BISECT_OPT=''
|
|
|
|
test -n "$skip" && BISECT_OPT='--bisect-all'
|
|
|
|
eval="git rev-list --bisect-vars $BISECT_OPT $good $bad --" &&
|
2007-04-06 10:27:44 +04:00
|
|
|
eval="$eval $(cat "$GIT_DIR/BISECT_NAMES")" &&
|
2007-10-22 09:48:36 +04:00
|
|
|
eval=$(filter_skipped "$eval" "$skip") &&
|
2007-04-06 10:27:44 +04:00
|
|
|
eval "$eval" || exit
|
|
|
|
|
|
|
|
if [ -z "$bisect_rev" ]; then
|
|
|
|
echo "$bad was both good and bad"
|
|
|
|
exit 1
|
2005-08-30 22:04:39 +04:00
|
|
|
fi
|
2007-04-06 10:27:44 +04:00
|
|
|
if [ "$bisect_rev" = "$bad" ]; then
|
2007-10-22 09:48:36 +04:00
|
|
|
exit_if_skipped_commits "$bisect_tried"
|
2007-04-06 10:27:44 +04:00
|
|
|
echo "$bisect_rev is first bad commit"
|
2007-07-03 09:52:14 +04:00
|
|
|
git diff-tree --pretty $bisect_rev
|
2007-04-06 10:27:44 +04:00
|
|
|
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-30 21:08:20 +04:00
|
|
|
fi
|
2007-04-06 10:27:44 +04:00
|
|
|
|
2007-10-22 09:48:36 +04:00
|
|
|
# We should exit here only if the "bad"
|
|
|
|
# commit is also a "skip" commit (see above).
|
|
|
|
exit_if_skipped_commits "$bisect_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>
2008-08-22 07:52:22 +04:00
|
|
|
bisect_checkout "$bisect_rev" "$bisect_nr revisions left to test after this"
|
[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-30 21:08:20 +04:00
|
|
|
}
|
|
|
|
|
2005-08-30 23:45:41 +04:00
|
|
|
bisect_visualize() {
|
|
|
|
bisect_next_check fail
|
2007-12-07 13:25:34 +03:00
|
|
|
|
|
|
|
if test $# = 0
|
|
|
|
then
|
2008-02-14 15:29:58 +03:00
|
|
|
case "${DISPLAY+set}${MSYSTEM+set}${SECURITYSESSIONID+set}" in
|
2007-12-07 13:25:34 +03:00
|
|
|
'') set git log ;;
|
2008-02-14 15:29:58 +03:00
|
|
|
set*) set gitk ;;
|
2007-12-07 13:25:34 +03:00
|
|
|
esac
|
|
|
|
else
|
|
|
|
case "$1" in
|
|
|
|
git*|tig) ;;
|
|
|
|
-*) set git log "$@" ;;
|
|
|
|
*) set git "$@" ;;
|
|
|
|
esac
|
|
|
|
fi
|
|
|
|
|
2007-11-17 16:35:25 +03:00
|
|
|
not=$(git for-each-ref --format='%(refname)' "refs/bisect/good-*")
|
2007-12-07 13:25:34 +03:00
|
|
|
eval '"$@"' refs/bisect/bad --not $not -- $(cat "$GIT_DIR/BISECT_NAMES")
|
2005-08-30 23:45:41 +04:00
|
|
|
}
|
|
|
|
|
[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-30 21:08:20 +04:00
|
|
|
bisect_reset() {
|
2008-05-28 20:57:02 +04:00
|
|
|
test -s "$GIT_DIR/BISECT_START" || {
|
2007-11-20 08:39:53 +03:00
|
|
|
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>
2005-07-30 21:08:20 +04:00
|
|
|
case "$#" in
|
2008-05-28 20:57:02 +04:00
|
|
|
0) branch=$(cat "$GIT_DIR/BISECT_START") ;;
|
2007-10-24 09:01:13 +04:00
|
|
|
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-30 21:08:20 +04:00
|
|
|
branch="$1" ;;
|
2007-10-22 09:48:23 +04:00
|
|
|
*)
|
[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-30 21:08:20 +04:00
|
|
|
usage ;;
|
|
|
|
esac
|
2008-05-23 02:38:59 +04:00
|
|
|
git checkout "$branch" && bisect_clean_state
|
2005-09-11 02:18:31 +04:00
|
|
|
}
|
|
|
|
|
2007-04-04 09:12:02 +04:00
|
|
|
bisect_clean_state() {
|
2007-11-15 10:18:07 +03:00
|
|
|
# There may be some refs packed during bisection.
|
2008-05-23 03:28:57 +04:00
|
|
|
git for-each-ref --format='%(refname) %(objectname)' refs/bisect/\* |
|
2007-11-15 10:18:07 +03:00
|
|
|
while read ref hash
|
|
|
|
do
|
2008-05-28 20:57:02 +04:00
|
|
|
git update-ref -d $ref $hash || exit
|
2007-11-15 10:18:07 +03:00
|
|
|
done
|
2008-08-22 07:52:29 +04:00
|
|
|
rm -f "$GIT_DIR/BISECT_EXPECTED_REV" &&
|
|
|
|
rm -f "$GIT_DIR/BISECT_ANCESTORS_OK" &&
|
2008-05-28 20:57:02 +04:00
|
|
|
rm -f "$GIT_DIR/BISECT_LOG" &&
|
|
|
|
rm -f "$GIT_DIR/BISECT_NAMES" &&
|
|
|
|
rm -f "$GIT_DIR/BISECT_RUN" &&
|
2008-05-23 02:38:59 +04:00
|
|
|
# Cleanup head-name if it got left by an old version of git-bisect
|
2008-05-28 20:57:02 +04:00
|
|
|
rm -f "$GIT_DIR/head-name" &&
|
|
|
|
|
|
|
|
rm -f "$GIT_DIR/BISECT_START"
|
2007-04-04 09:12:02 +04:00
|
|
|
}
|
|
|
|
|
2005-09-11 02:18:31 +04:00
|
|
|
bisect_replay () {
|
2007-10-24 09:01:13 +04:00
|
|
|
test -r "$1" || die "cannot read $1 for replaying"
|
2005-09-11 02:18:31 +04:00
|
|
|
bisect_reset
|
2008-07-11 20:01:29 +04:00
|
|
|
while read git bisect command rev
|
2005-09-11 02:18:31 +04:00
|
|
|
do
|
2008-07-11 20:01:29 +04:00
|
|
|
test "$git $bisect" = "git bisect" -o "$git" = "git-bisect" || continue
|
|
|
|
if test "$git" = "git-bisect"; then
|
|
|
|
rev="$command"
|
|
|
|
command="$bisect"
|
|
|
|
fi
|
2005-09-11 02:18:31 +04:00
|
|
|
case "$command" in
|
|
|
|
start)
|
2005-11-28 04:42:05 +03:00
|
|
|
cmd="bisect_start $rev"
|
2007-10-24 09:01:13 +04:00
|
|
|
eval "$cmd" ;;
|
|
|
|
good|bad|skip)
|
|
|
|
bisect_write "$command" "$rev" ;;
|
2005-09-11 02:18:31 +04:00
|
|
|
*)
|
2007-10-24 09:01:13 +04:00
|
|
|
die "?? what are you talking about?" ;;
|
2005-09-11 02:18:31 +04:00
|
|
|
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-30 21:08:20 +04:00
|
|
|
}
|
|
|
|
|
2007-03-23 10:49:59 +03:00
|
|
|
bisect_run () {
|
2007-03-27 08:49:57 +04:00
|
|
|
bisect_next_check fail
|
|
|
|
|
2007-03-23 10:49:59 +03:00
|
|
|
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
|
|
|
|
|
2007-10-24 09:01:21 +04:00
|
|
|
# Find current state depending on run success or failure.
|
2007-10-26 07:39:37 +04:00
|
|
|
# A special exit code of 125 means cannot test.
|
|
|
|
if [ $res -eq 125 ]; then
|
|
|
|
state='skip'
|
|
|
|
elif [ $res -gt 0 ]; then
|
2007-10-24 09:01:21 +04:00
|
|
|
state='bad'
|
2007-03-23 10:49:59 +03:00
|
|
|
else
|
2007-10-24 09:01:21 +04:00
|
|
|
state='good'
|
2007-03-23 10:49:59 +03:00
|
|
|
fi
|
|
|
|
|
2007-10-24 09:01:21 +04:00
|
|
|
# We have to use a subshell because "bisect_state" can exit.
|
|
|
|
( bisect_state $state > "$GIT_DIR/BISECT_RUN" )
|
2007-03-23 10:49:59 +03:00
|
|
|
res=$?
|
|
|
|
|
|
|
|
cat "$GIT_DIR/BISECT_RUN"
|
|
|
|
|
2007-10-26 07:39:37 +04:00
|
|
|
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
|
|
|
|
|
2007-03-23 10:49:59 +03:00
|
|
|
if [ $res -ne 0 ]; then
|
|
|
|
echo >&2 "bisect run failed:"
|
2007-10-24 09:01:21 +04:00
|
|
|
echo >&2 "'bisect_state $state' exited with error code $res"
|
2007-03-23 10:49:59 +03:00
|
|
|
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-30 21:08:20 +04:00
|
|
|
case "$#" in
|
|
|
|
0)
|
|
|
|
usage ;;
|
|
|
|
*)
|
|
|
|
cmd="$1"
|
|
|
|
shift
|
|
|
|
case "$cmd" in
|
2008-04-11 07:55:21 +04:00
|
|
|
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>
2005-07-30 21:08:20 +04:00
|
|
|
start)
|
|
|
|
bisect_start "$@" ;;
|
2007-10-24 09:01:21 +04:00
|
|
|
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-30 21:08:20 +04:00
|
|
|
next)
|
|
|
|
# Not sure we want "next" at the UI level anymore.
|
|
|
|
bisect_next "$@" ;;
|
2007-12-07 13:25:34 +03:00
|
|
|
visualize|view)
|
2005-08-30 23:45:41 +04:00
|
|
|
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-30 21:08:20 +04:00
|
|
|
reset)
|
|
|
|
bisect_reset "$@" ;;
|
2005-09-11 02:18:31 +04:00
|
|
|
replay)
|
|
|
|
bisect_replay "$@" ;;
|
|
|
|
log)
|
|
|
|
cat "$GIT_DIR/BISECT_LOG" ;;
|
2007-03-23 10:49:59 +03:00
|
|
|
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-30 21:08:20 +04:00
|
|
|
*)
|
|
|
|
usage ;;
|
|
|
|
esac
|
|
|
|
esac
|