So the build was broken somewhere in between release-1.0 and master HEAD. To find the exact one you just need to run two git commands. First
$ git bisect start HEAD release-1.0
Here you specify which commit you know is broken, and which one you remember was successful. After running this command you can see that git marked two commits with good and bad labels, and put the search starting point at the revision in the middle.
The second command is git bisect run cmd, where cmd is the script used as a criterion of successful build. If you use Maven then your command would be:
$ git bisect run mvn clean test
After you hit Enter button in the terminal, git starts running your criterion script using binary search algorithm. It might take time to finish this task, which depends on the number of revisions and the execution time of the script. Eventually it stops and shows you which commit caused the build failure.
7933e4658ea852754120fbc8fec34b2b85932e48 is first bad commit
commit 7933e4658ea852754120fbc8fec34b2b85932e48
Author: Andrey Paramonov
Date: Wed Nov 25 21:07:30 2009 -0500
Changed method implementation
:040000 040000 c0f3f9ef13d7daa4671205b9518c168a9ac10fe3 5a1cf3d6fb28d6f815c172319630b5d55ce4dc10 M src
bisect run success
If you look at the visual tool, you will spot the first bad commit by the label bisect/bad.
Resources
• git-bisect manual page
1 comment:
Yes, git-bisect is a cool feature. I like also git-rebase. It's a powerful beast when you know how to use it.
- Eugene Ossintsev
Post a Comment