[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
|
|
|
|
2017-11-12 12:30:38 +03:00
|
|
|
USAGE='[help|start|bad|good|new|old|terms|skip|next|reset|visualize|view|replay|log|run]'
|
2008-04-11 07:55:21 +04:00
|
|
|
LONG_USAGE='git bisect help
|
2011-08-05 15:31:30 +04:00
|
|
|
print this long help message.
|
2015-06-29 18:40:35 +03:00
|
|
|
git bisect start [--term-{old,good}=<term> --term-{new,bad}=<term>]
|
|
|
|
[--no-checkout] [<bad> [<good>...]] [--] [<pathspec>...]
|
2011-08-05 15:31:30 +04:00
|
|
|
reset bisect state and start bisection.
|
2015-06-29 18:40:33 +03:00
|
|
|
git bisect (bad|new) [<rev>]
|
|
|
|
mark <rev> a known-bad revision/
|
|
|
|
a revision after change in a given property.
|
|
|
|
git bisect (good|old) [<rev>...]
|
|
|
|
mark <rev>... known-good revisions/
|
|
|
|
revisions before change in a given property.
|
2015-06-29 18:40:34 +03:00
|
|
|
git bisect terms [--term-good | --term-bad]
|
|
|
|
show the terms used for old and new commits (default: bad, good)
|
2008-12-02 16:53:51 +03:00
|
|
|
git bisect skip [(<rev>|<range>)...]
|
2011-08-05 15:31:30 +04:00
|
|
|
mark <rev>... untestable revisions.
|
2007-04-04 09:12:02 +04:00
|
|
|
git bisect next
|
2011-08-05 15:31:30 +04:00
|
|
|
find next bisection to test and check it out.
|
2009-10-14 01:02:24 +04:00
|
|
|
git bisect reset [<commit>]
|
2011-08-05 15:31:30 +04:00
|
|
|
finish bisection search and go back to commit.
|
2017-11-12 12:30:38 +03:00
|
|
|
git bisect (visualize|view)
|
2011-08-05 15:31:30 +04:00
|
|
|
show bisect status in gitk.
|
2007-04-04 09:12:02 +04:00
|
|
|
git bisect replay <logfile>
|
2011-08-05 15:31:30 +04:00
|
|
|
replay bisection log.
|
2007-04-04 09:12:02 +04:00
|
|
|
git bisect log
|
2011-08-05 15:31:30 +04:00
|
|
|
show bisect log.
|
2007-04-04 09:12:02 +04:00
|
|
|
git bisect run <cmd>...
|
2011-08-05 15:31:30 +04:00
|
|
|
use <cmd>... to automatically bisect.
|
2008-04-11 07:55:21 +04:00
|
|
|
|
|
|
|
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
|
[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"
|
2015-06-29 18:40:29 +03:00
|
|
|
TERM_BAD=bad
|
|
|
|
TERM_GOOD=good
|
2008-02-10 16:59:50 +03:00
|
|
|
|
2011-08-04 16:01:01 +04:00
|
|
|
bisect_head()
|
|
|
|
{
|
|
|
|
if test -f "$GIT_DIR/BISECT_HEAD"
|
|
|
|
then
|
|
|
|
echo BISECT_HEAD
|
|
|
|
else
|
|
|
|
echo HEAD
|
|
|
|
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
|
|
|
bisect_autostart() {
|
2008-05-28 20:57:02 +04:00
|
|
|
test -s "$GIT_DIR/BISECT_START" || {
|
2011-08-31 03:09:47 +04:00
|
|
|
gettextln "You need to start by \"git bisect start\"" >&2
|
[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
|
|
|
if test -t 0
|
|
|
|
then
|
2011-05-21 22:44:28 +04:00
|
|
|
# TRANSLATORS: Make sure to include [Y] and [n] in your
|
|
|
|
# translation. The program will only accept English input
|
|
|
|
# at this point.
|
2011-08-05 15:31:30 +04:00
|
|
|
gettext "Do you want me to do it for you [Y/n]? " >&2
|
[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
|
|
|
read yesno
|
|
|
|
case "$yesno" in
|
|
|
|
[Nn]*)
|
|
|
|
exit ;;
|
|
|
|
esac
|
|
|
|
bisect_start
|
|
|
|
else
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bisect_start() {
|
2019-01-02 18:38:36 +03:00
|
|
|
git bisect--helper --bisect-start $@ || exit
|
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".
|
|
|
|
#
|
2017-09-29 09:49:39 +03:00
|
|
|
trap 'git bisect--helper --bisect-clean-state' 0
|
2008-05-23 02:39:22 +04:00
|
|
|
trap 'exit 255' 1 2 3 15
|
|
|
|
|
|
|
|
#
|
|
|
|
# Check if we can proceed to the next bisect state.
|
|
|
|
#
|
2019-01-02 18:38:36 +03:00
|
|
|
get_terms
|
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
|
|
|
}
|
|
|
|
|
2008-11-24 00:02:49 +03:00
|
|
|
bisect_skip() {
|
2011-08-05 15:31:30 +04:00
|
|
|
all=''
|
2008-11-24 00:02:49 +03:00
|
|
|
for arg in "$@"
|
|
|
|
do
|
2011-08-05 15:31:30 +04:00
|
|
|
case "$arg" in
|
|
|
|
*..*)
|
|
|
|
revs=$(git rev-list "$arg") || die "$(eval_gettext "Bad rev input: \$arg")" ;;
|
|
|
|
*)
|
|
|
|
revs=$(git rev-parse --sq-quote "$arg") ;;
|
|
|
|
esac
|
|
|
|
all="$all $revs"
|
|
|
|
done
|
|
|
|
eval bisect_state 'skip' $all
|
2008-11-24 00:02:49 +03:00
|
|
|
}
|
|
|
|
|
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
|
2019-01-02 18:38:33 +03:00
|
|
|
git bisect--helper --check-and-set-terms $state $TERM_GOOD $TERM_BAD || exit
|
|
|
|
get_terms
|
2007-10-24 09:01:21 +04:00
|
|
|
case "$#,$state" in
|
|
|
|
0,*)
|
2016-06-18 00:54:14 +03:00
|
|
|
die "Please call 'bisect_state' with at least one argument." ;;
|
2015-06-29 18:40:29 +03:00
|
|
|
1,"$TERM_BAD"|1,"$TERM_GOOD"|1,skip)
|
2016-06-17 23:21:00 +03:00
|
|
|
bisected_head=$(bisect_head)
|
|
|
|
rev=$(git rev-parse --verify "$bisected_head") ||
|
|
|
|
die "$(eval_gettext "Bad rev input: \$bisected_head")"
|
2019-01-02 18:38:32 +03:00
|
|
|
git bisect--helper --bisect-write "$state" "$rev" "$TERM_GOOD" "$TERM_BAD" || exit
|
2017-09-29 09:49:40 +03:00
|
|
|
git bisect--helper --check-expected-revs "$rev" ;;
|
2015-06-29 18:40:29 +03:00
|
|
|
2,"$TERM_BAD"|*,"$TERM_GOOD"|*,skip)
|
2007-10-24 09:01:21 +04:00
|
|
|
shift
|
2014-12-25 21:25:32 +03:00
|
|
|
hash_list=''
|
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}") ||
|
2011-05-21 22:44:24 +04:00
|
|
|
die "$(eval_gettext "Bad rev input: \$rev")"
|
2014-12-25 21:25:32 +03:00
|
|
|
hash_list="$hash_list $sha"
|
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
|
|
|
done
|
2014-12-25 21:25:32 +03:00
|
|
|
for rev in $hash_list
|
|
|
|
do
|
2019-01-02 18:38:32 +03:00
|
|
|
git bisect--helper --bisect-write "$state" "$rev" "$TERM_GOOD" "$TERM_BAD" || exit
|
2014-12-25 21:25:32 +03:00
|
|
|
done
|
2017-09-29 09:49:40 +03:00
|
|
|
git bisect--helper --check-expected-revs $hash_list ;;
|
2015-06-29 18:40:29 +03:00
|
|
|
*,"$TERM_BAD")
|
|
|
|
die "$(eval_gettext "'git bisect \$TERM_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_auto_next() {
|
2019-01-02 18:38:34 +03:00
|
|
|
git bisect--helper --bisect-next-check $TERM_GOOD $TERM_BAD && 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
|
|
|
}
|
|
|
|
|
|
|
|
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
|
2019-01-02 18:38:34 +03:00
|
|
|
git bisect--helper --bisect-next-check $TERM_GOOD $TERM_BAD $TERM_GOOD|| exit
|
2007-04-06 10:27:44 +04:00
|
|
|
|
2009-05-09 19:55:47 +04:00
|
|
|
# Perform all bisection computation, display and checkout
|
2011-08-04 16:01:01 +04:00
|
|
|
git bisect--helper --next-all $(test -f "$GIT_DIR/BISECT_HEAD" && echo --no-checkout)
|
2009-04-19 13:56:16 +04:00
|
|
|
res=$?
|
2007-04-06 10:27:44 +04:00
|
|
|
|
2011-08-05 15:31:30 +04:00
|
|
|
# Check if we should exit because bisection is finished
|
2013-04-13 19:22:57 +04:00
|
|
|
if test $res -eq 10
|
|
|
|
then
|
2015-06-29 18:40:29 +03:00
|
|
|
bad_rev=$(git show-ref --hash --verify refs/bisect/$TERM_BAD)
|
2013-04-13 19:22:57 +04:00
|
|
|
bad_commit=$(git show-branch $bad_rev)
|
2015-06-29 18:40:29 +03:00
|
|
|
echo "# first $TERM_BAD commit: $bad_commit" >>"$GIT_DIR/BISECT_LOG"
|
2013-04-13 19:22:57 +04:00
|
|
|
exit 0
|
2013-04-23 01:02:29 +04:00
|
|
|
elif test $res -eq 2
|
|
|
|
then
|
|
|
|
echo "# only skipped commits left to test" >>"$GIT_DIR/BISECT_LOG"
|
2015-06-29 18:40:29 +03:00
|
|
|
good_revs=$(git for-each-ref --format="%(objectname)" "refs/bisect/$TERM_GOOD-*")
|
|
|
|
for skipped in $(git rev-list refs/bisect/$TERM_BAD --not $good_revs)
|
2013-04-23 01:02:29 +04:00
|
|
|
do
|
|
|
|
skipped_commit=$(git show-branch $skipped)
|
2015-06-29 18:40:29 +03:00
|
|
|
echo "# possible first $TERM_BAD commit: $skipped_commit" >>"$GIT_DIR/BISECT_LOG"
|
2013-04-23 01:02:29 +04:00
|
|
|
done
|
|
|
|
exit $res
|
2013-04-13 19:22:57 +04:00
|
|
|
fi
|
2007-04-06 10:27:44 +04:00
|
|
|
|
2009-04-19 13:56:16 +04:00
|
|
|
# Check for an error in the bisection process
|
|
|
|
test $res -ne 0 && exit $res
|
|
|
|
|
|
|
|
return 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
|
|
|
}
|
|
|
|
|
2005-08-30 23:45:41 +04:00
|
|
|
bisect_visualize() {
|
2019-01-02 18:38:34 +03:00
|
|
|
git bisect--helper --bisect-next-check $TERM_GOOD $TERM_BAD fail || exit
|
2007-12-07 13:25:34 +03:00
|
|
|
|
|
|
|
if test $# = 0
|
|
|
|
then
|
2011-03-21 16:14:22 +03:00
|
|
|
if test -n "${DISPLAY+set}${SESSIONNAME+set}${MSYSTEM+set}${SECURITYSESSIONID+set}" &&
|
2011-08-05 21:09:23 +04:00
|
|
|
type gitk >/dev/null 2>&1
|
2011-08-05 15:31:31 +04:00
|
|
|
then
|
2011-03-21 16:14:22 +03:00
|
|
|
set gitk
|
|
|
|
else
|
|
|
|
set git log
|
|
|
|
fi
|
2007-12-07 13:25:34 +03:00
|
|
|
else
|
|
|
|
case "$1" in
|
|
|
|
git*|tig) ;;
|
|
|
|
-*) set git log "$@" ;;
|
|
|
|
*) set git "$@" ;;
|
|
|
|
esac
|
|
|
|
fi
|
|
|
|
|
2009-11-23 07:16:14 +03:00
|
|
|
eval '"$@"' --bisect -- $(cat "$GIT_DIR/BISECT_NAMES")
|
2005-08-30 23:45:41 +04:00
|
|
|
}
|
|
|
|
|
2005-09-11 02:18:31 +04:00
|
|
|
bisect_replay () {
|
2011-05-21 22:44:27 +04:00
|
|
|
file="$1"
|
|
|
|
test "$#" -eq 1 || die "$(gettext "No logfile given")"
|
|
|
|
test -r "$file" || die "$(eval_gettext "cannot read \$file for replaying")"
|
2019-01-02 18:38:31 +03:00
|
|
|
git bisect--helper --bisect-reset || exit
|
2008-07-11 20:01:29 +04:00
|
|
|
while read git bisect command rev
|
2005-09-11 02:18:31 +04:00
|
|
|
do
|
2014-06-06 18:55:50 +04:00
|
|
|
test "$git $bisect" = "git bisect" || test "$git" = "git-bisect" || continue
|
2011-08-05 15:31:31 +04:00
|
|
|
if test "$git" = "git-bisect"
|
|
|
|
then
|
2008-07-11 20:01:29 +04:00
|
|
|
rev="$command"
|
|
|
|
command="$bisect"
|
|
|
|
fi
|
2015-06-29 18:40:30 +03:00
|
|
|
get_terms
|
2019-01-02 18:38:33 +03:00
|
|
|
git bisect--helper --check-and-set-terms "$command" "$TERM_GOOD" "$TERM_BAD" || exit
|
|
|
|
get_terms
|
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" ;;
|
2015-06-29 18:40:30 +03:00
|
|
|
"$TERM_GOOD"|"$TERM_BAD"|skip)
|
2019-01-02 18:38:32 +03:00
|
|
|
git bisect--helper --bisect-write "$command" "$rev" "$TERM_GOOD" "$TERM_BAD" || exit;;
|
2015-06-29 18:40:34 +03:00
|
|
|
terms)
|
2019-01-02 18:38:35 +03:00
|
|
|
git bisect--helper --bisect-terms $rev || exit;;
|
2005-09-11 02:18:31 +04:00
|
|
|
*)
|
2011-05-21 22:44:23 +04:00
|
|
|
die "$(gettext "?? what are you talking about?")" ;;
|
2005-09-11 02:18:31 +04:00
|
|
|
esac
|
2011-05-21 22:44:27 +04:00
|
|
|
done <"$file"
|
2005-09-11 02:18:31 +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
|
|
|
}
|
|
|
|
|
2007-03-23 10:49:59 +03:00
|
|
|
bisect_run () {
|
2019-01-02 18:38:34 +03:00
|
|
|
git bisect--helper --bisect-next-check $TERM_GOOD $TERM_BAD fail || exit
|
2011-08-05 15:31:30 +04:00
|
|
|
|
2017-11-12 23:55:33 +03:00
|
|
|
test -n "$*" || die "$(gettext "bisect run failed: no command provided.")"
|
|
|
|
|
2011-08-05 15:31:30 +04:00
|
|
|
while true
|
|
|
|
do
|
|
|
|
command="$@"
|
2011-08-31 03:09:47 +04:00
|
|
|
eval_gettextln "running \$command"
|
2011-08-05 15:31:30 +04:00
|
|
|
"$@"
|
|
|
|
res=$?
|
|
|
|
|
|
|
|
# Check for really bad run error.
|
2011-08-05 15:31:31 +04:00
|
|
|
if [ $res -lt 0 -o $res -ge 128 ]
|
|
|
|
then
|
2011-08-31 03:09:47 +04:00
|
|
|
eval_gettextln "bisect run failed:
|
|
|
|
exit code \$res from '\$command' is < 0 or >= 128" >&2
|
2011-08-05 15:31:30 +04:00
|
|
|
exit $res
|
|
|
|
fi
|
|
|
|
|
|
|
|
# Find current state depending on run success or failure.
|
|
|
|
# A special exit code of 125 means cannot test.
|
2011-08-05 15:31:31 +04:00
|
|
|
if [ $res -eq 125 ]
|
|
|
|
then
|
2011-08-05 15:31:30 +04:00
|
|
|
state='skip'
|
2011-08-05 15:31:31 +04:00
|
|
|
elif [ $res -gt 0 ]
|
|
|
|
then
|
2015-06-29 18:40:29 +03:00
|
|
|
state="$TERM_BAD"
|
2011-08-05 15:31:30 +04:00
|
|
|
else
|
2015-06-29 18:40:29 +03:00
|
|
|
state="$TERM_GOOD"
|
2011-08-05 15:31:30 +04:00
|
|
|
fi
|
|
|
|
|
|
|
|
# We have to use a subshell because "bisect_state" can exit.
|
2014-03-04 04:21:43 +04:00
|
|
|
( bisect_state $state >"$GIT_DIR/BISECT_RUN" )
|
2011-08-05 15:31:30 +04:00
|
|
|
res=$?
|
|
|
|
|
|
|
|
cat "$GIT_DIR/BISECT_RUN"
|
|
|
|
|
2015-06-29 18:40:29 +03:00
|
|
|
if sane_grep "first $TERM_BAD commit could be any of" "$GIT_DIR/BISECT_RUN" \
|
2014-03-04 04:21:43 +04:00
|
|
|
>/dev/null
|
2011-08-05 15:31:31 +04:00
|
|
|
then
|
2011-08-31 03:09:47 +04:00
|
|
|
gettextln "bisect run cannot continue any more" >&2
|
2011-08-05 15:31:30 +04:00
|
|
|
exit $res
|
|
|
|
fi
|
|
|
|
|
2011-08-05 15:31:31 +04:00
|
|
|
if [ $res -ne 0 ]
|
|
|
|
then
|
2011-08-31 03:09:47 +04:00
|
|
|
eval_gettextln "bisect run failed:
|
|
|
|
'bisect_state \$state' exited with error code \$res" >&2
|
2011-08-05 15:31:30 +04:00
|
|
|
exit $res
|
|
|
|
fi
|
2007-03-23 10:49:59 +03:00
|
|
|
|
2015-06-29 18:40:29 +03:00
|
|
|
if sane_grep "is the first $TERM_BAD commit" "$GIT_DIR/BISECT_RUN" >/dev/null
|
2011-08-05 15:31:31 +04:00
|
|
|
then
|
2011-08-31 03:09:47 +04:00
|
|
|
gettextln "bisect run success"
|
2011-08-05 15:31:30 +04:00
|
|
|
exit 0;
|
|
|
|
fi
|
2007-03-23 10:49:59 +03:00
|
|
|
|
2011-08-05 15:31:30 +04:00
|
|
|
done
|
2007-03-23 10:49:59 +03:00
|
|
|
}
|
|
|
|
|
2010-10-11 01:48:56 +04:00
|
|
|
bisect_log () {
|
2011-05-21 22:44:23 +04:00
|
|
|
test -s "$GIT_DIR/BISECT_LOG" || die "$(gettext "We are not bisecting.")"
|
2010-10-11 01:48:56 +04:00
|
|
|
cat "$GIT_DIR/BISECT_LOG"
|
|
|
|
}
|
2007-03-23 10:49:59 +03:00
|
|
|
|
2015-06-29 18:40:30 +03:00
|
|
|
get_terms () {
|
|
|
|
if test -s "$GIT_DIR/BISECT_TERMS"
|
|
|
|
then
|
|
|
|
{
|
|
|
|
read TERM_BAD
|
|
|
|
read TERM_GOOD
|
|
|
|
} <"$GIT_DIR/BISECT_TERMS"
|
|
|
|
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
|
|
|
case "$#" in
|
|
|
|
0)
|
2011-08-05 15:31:30 +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
|
|
|
*)
|
2011-08-05 15:31:30 +04:00
|
|
|
cmd="$1"
|
2015-06-29 18:40:30 +03:00
|
|
|
get_terms
|
2011-08-05 15:31:30 +04:00
|
|
|
shift
|
|
|
|
case "$cmd" in
|
|
|
|
help)
|
|
|
|
git bisect -h ;;
|
|
|
|
start)
|
|
|
|
bisect_start "$@" ;;
|
2015-06-29 18:40:33 +03:00
|
|
|
bad|good|new|old|"$TERM_BAD"|"$TERM_GOOD")
|
2011-08-05 15:31:30 +04:00
|
|
|
bisect_state "$cmd" "$@" ;;
|
|
|
|
skip)
|
|
|
|
bisect_skip "$@" ;;
|
|
|
|
next)
|
|
|
|
# Not sure we want "next" at the UI level anymore.
|
|
|
|
bisect_next "$@" ;;
|
|
|
|
visualize|view)
|
|
|
|
bisect_visualize "$@" ;;
|
|
|
|
reset)
|
2019-01-02 18:38:31 +03:00
|
|
|
git bisect--helper --bisect-reset "$@" ;;
|
2011-08-05 15:31:30 +04:00
|
|
|
replay)
|
|
|
|
bisect_replay "$@" ;;
|
|
|
|
log)
|
|
|
|
bisect_log ;;
|
|
|
|
run)
|
|
|
|
bisect_run "$@" ;;
|
2015-06-29 18:40:34 +03:00
|
|
|
terms)
|
2019-01-02 18:38:35 +03:00
|
|
|
git bisect--helper --bisect-terms "$@" || exit;;
|
2011-08-05 15:31:30 +04:00
|
|
|
*)
|
|
|
|
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
|
|
|
esac
|