0

The normal use case for 'git bisect' is to declare the tip of the reference the 'bad' state, and search the history for the lastest 'good' state. This makes sense when searching for a commit that introduced a bug.

However, sometimes a bug is discovered in older code, which is fixed in the newest commit, and the question is: which commit fixed this bug? It is possible to use git bisect with a reversed sense of the words "good" and "bad", i.e. consider the fixed bug to be the "bad" state and the bug to be the "good" state. But that's a little confusing - it might be more clear to start a bisect at a "good" state and search back for a "bad" state. But git doesn't seem to like that approach:

$ git bisect start
$ git bisect good
$ git checkout <commit with known bug>
$ git bisect bad
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?

What's a good way to handle this case?

gcbenison
  • 11,723
  • 4
  • 44
  • 82
  • 8
    possible duplicate of [How could I use git bisect to find the first GOOD commit?](http://stackoverflow.com/questions/15407075/how-could-i-use-git-bisect-to-find-the-first-good-commit) – Zaz Jul 09 '14 at 13:40

1 Answers1

3

You might have noticed that git is not that much about “pretty-looking” and “intuitive interface”. You did guess the answer and the proper git way: just think of fixed as bad and not fixed as good.

Since this perfectly handles your (less common) case apart from being a little bit ugly, there does not need to be special support for it in git, and you can assume that there never will.

Edit: I was wrong. Git added support for this in version 2.7 – see this answer.

Chronial
  • 66,706
  • 14
  • 93
  • 99