git bisect
Posted 12-02-2009 at 12:37 AM by vkmgeek
All,
We were chasing one hard-to-solve bug few days back. There was no clue from HW or SW perspective. And yet we had to chase a bug. A typical Indian Software Developer's condition
However, I have been hearing about git-bisect since a long time on kernel community. And I wanted to practice that. So, this was the opportunity. I decided to track this down using git bisect. It's a nice way which probably CVS user lacks.
git bisect basically gives you your git tree at different points.
So,
Q. When should you use ?
A. When you do not have much idea about the problem. 2. When you know that few time back there was not such problem and it is introduced in some near future but dont know when. You should use git bisect method.
Q. How to use?
Well, first of all, you need to decide two git commits. One BAD commit with which you can reproduce a certain bug. And another GOOD commit where you know that there was not any bug with that version of git.
Once you decide, you tell
#git bisect start
#git bisect good
#git bisect bad
Now, git really bisects your git tree. It uses binary search to find out first BAD commit. And first and last limit for that binary search is good and bad commits that you have specified.
Now, after first bisection, you can test the code. If the test is PASS, you can say
# git bisect good
or if your test fails, you can say
#git bisect bad
After that git again bisects for you and it displays how many revisions are still needs to be tested to conclude on first BAD commit.
You keep saying eihter "git bisect good" or "git bisect bad"
At the end, whatever .git/refs/bisect/bad refers is first BAD commit.
That was easy-to-start with git bisect. There are various other options as well using them you can really make debugging faster.
1. If you know, particular commit during bisecting is good, you can say
#git bisect skip
2. You can make a script which can do test for you and then you dont need any manual intervention at all
#git bisect run
Note that, your script returns 0 then it is assumed that "git bisect good" or if it returns -ve values, it will be concluded as "git bisect bad"
3. At the end, you can replay whole process, just say
#git bisect replay
or
#git bisect log
We were chasing one hard-to-solve bug few days back. There was no clue from HW or SW perspective. And yet we had to chase a bug. A typical Indian Software Developer's condition
However, I have been hearing about git-bisect since a long time on kernel community. And I wanted to practice that. So, this was the opportunity. I decided to track this down using git bisect. It's a nice way which probably CVS user lacks.
git bisect basically gives you your git tree at different points.
So,
Q. When should you use ?
A. When you do not have much idea about the problem. 2. When you know that few time back there was not such problem and it is introduced in some near future but dont know when. You should use git bisect method.
Q. How to use?
Well, first of all, you need to decide two git commits. One BAD commit with which you can reproduce a certain bug. And another GOOD commit where you know that there was not any bug with that version of git.
Once you decide, you tell
#git bisect start
#git bisect good
#git bisect bad
Now, git really bisects your git tree. It uses binary search to find out first BAD commit. And first and last limit for that binary search is good and bad commits that you have specified.
Now, after first bisection, you can test the code. If the test is PASS, you can say
# git bisect good
or if your test fails, you can say
#git bisect bad
After that git again bisects for you and it displays how many revisions are still needs to be tested to conclude on first BAD commit.
You keep saying eihter "git bisect good" or "git bisect bad"
At the end, whatever .git/refs/bisect/bad refers is first BAD commit.
That was easy-to-start with git bisect. There are various other options as well using them you can really make debugging faster.
1. If you know, particular commit during bisecting is good, you can say
#git bisect skip
2. You can make a script which can do test for you and then you dont need any manual intervention at all
#git bisect run
Note that, your script returns 0 then it is assumed that "git bisect good" or if it returns -ve values, it will be concluded as "git bisect bad"
3. At the end, you can replay whole process, just say
#git bisect replay
or
#git bisect log
Total Comments 0
