git bisect

 from: https://git-scm.com/docs/git-bisect

Basic bisect commands: start, bad, good

As an example, suppose you are trying to find the commit that broke a feature that was known to work in version v2.6.13-rc2 of your project. You start a bisect session as follows:

$ git bisect start
$ git bisect bad                 # Current version is bad
$ git bisect good v2.6.13-rc2    # v2.6.13-rc2 is known to be good

Once you have specified at least one bad and one good commit, git bisect selects a commit in the middle of that range of history, checks it out, and outputs something similar to the following:

Bisecting: 675 revisions left to test after this (roughly 10 steps)

You should now compile the checked-out version and test it. If that version works correctly, type

$ git bisect good

If that version is broken, type

$ git bisect bad

Then git bisect will respond with something like

Bisecting: 337 revisions left to test after this (roughly 9 steps)

Keep repeating the process: compile the tree, test it, and depending on whether it is good or bad run git bisect good or git bisect bad to ask for the next commit that needs testing.

Eventually there will be no more revisions left to inspect, and the command will print out a description of the first bad commit. The reference refs/bisect/bad will be left pointing at that commit.

--- --- ---

current status:

steve@E5430:~/Projects/kstars$ git bisect start
steve@E5430:~/Projects/kstars$ git bisect bad
steve@E5430:~/Projects/kstars$ git bisect good 3369e6afa815a6d1e2089f417eade08d69e668a2
Bisecting: 85 revisions left to test after this (roughly 6 steps)
[361d241d3d76b53cc92bc98dbb237c4fe6d79000] Use upstream CMake config for Eigen

DON'T forget to build after each bisect. THEN test.