1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-06 17:23:00 +01:00
Commit graph

2 commits

Author SHA1 Message Date
Junio C Hamano
7f47e72fb3 git-bisect termination condition fix.
When I munged the original from Linus, which did not terminate
when the last bisect to check happened to be a bad one, to
terminate, I seem to have botched the end result to pick.

Thanks for Sanjoy Mahajan for a good reproduction recipe to
diagnose this.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 02:46:46 -07:00
Linus Torvalds
8cc6a08319 [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 14:03:14 -07:00