How could I use git bisect to find the first GOOD commit?

I have the following problem:

  • master version works fine
  • the version of the last tag before master (say last ) has an error
  • colleague needs a patch for his last version for this error

Good. Let me ask our friend git bisect for a bug fix:

 git bisect start git bisect bad last git bisect good master 

But this will not work:

Some good turnovers are not the ancestors of bad turnovers.
git bisect may not work properly in this case.
Maybe you are mistaken in good and bad turns?

Any hints to overcome this? Am I missing something in the docs?

+60
git
Mar 14 '13 at 10:47
source share
5 answers

As with git 2.7, you can use the --term-old and -term-new arguments.

For example, you can identify the fixation of a problem this way:

 git bisect start --term-new=fixed --term-old=unfixed git bisect fixed master git bisect unfixed $some-old-sha1 

When you are testing, say git bisect fixed or git bisect unfixed if necessary.

Old answer, for git versions prior to 2.7

Instead of temporarily teaching yourself to think that bad means good and good means bad, why not create some nicknames?

In ~/.gitconfig add the following:

 [alias] bisect-fixed = bisect bad bisect-unfixed = bisect good 

You can begin to fix the problem in this way:

 $ git bisect start $ git bisect-fixed master $ git bisect-unfixed $some-old-sha1 

When you test, say git bisect-fixed or git bisect-unfixed if necessary.

+52
Jun 17 '13 at 17:45
source share

I would just “cheat” git and replace the good <=> bad values.

In other words, consider “bad” as something that doesn't show a problem, so this is not a “good” version to base your patch on.

Good and bad are pretty subjective concepts, anyway? :)

 git bisect start git bisect good last git bisect bad master 
+42
Mar 14 '13 at 10:53 on
source share

If you use git bisect run , as I did with the Perl prove command (which runs automated tests), you have no chance of exchanging good and bad . The success of the tests will be reported as an exit code.

I found a valid Bash syntax to hide the exit code of a program executed by git bisect run :

 git bisect start git bisect bad HEAD # last revision known to PASS the tests git bisect good $LAST_FAIL_REVISION # last revision known to FAIL the tests git bisect run bash -c "! prove" 

This gave me the first revision to go through the tests performed by prove .

+14
Mar 22 '16 at 2:54 on
source share

Git aliases are a good idea, however the terms fixed and unfixed have the same problem than good and bad : you cannot be compatible with both regression and progression. It’s easy to find words that work anyway: just select them from the original binary search terminology, which is neutral in nature, without prejudice about what is good or bad. For example:

 git config --global alias.bisect-high 'bisect bad' git config --global alias.bisect-low 'bisect good' 

With these neutral terms, you can always enter: git bisect-high (or git bisect-upper , or git-bisect max , ... your choice!) Regardless of whether you are looking for regression or correction.

Too bad, bisect git developers could not just reuse any of the existing terms. The user interface does not apply to git at all: http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/

+5
Feb 19 '15 at 0:07
source share

Git now allows you to use old and new without defining them. You should call git bisect start without commits as additional arguments, then correctly start the halving by calling

 git bisect old <rev> git bisect new <rev> 

https://git-scm.com/docs/git-bisect#_alternate_terms

In essence, this @MarcH proposal should be implemented.

+3
Dec 25 '16 at 16:21
source share



All Articles