| 3 | | This page contains developer documentation that is useful, but rarely needed. |
| | 3 | This page contains developer documentation that is useful, but not needed often. |
| | 4 | |
| | 5 | = Bisecting commits to detect introduction of a bug = |
| | 6 | |
| | 7 | In most cases, it's easiest to use [http://book.git-scm.com/5_finding_issues_-_git_bisect.html git-bisect] to find the commit which introduced a problem. However, if the buildsystem is not in perfect working order all the way through from ''last known good'' commit to ''known bad'', you may need to do manual bisecting such as was done [ticket:190 here]. In practice, you can reset to an earlier commit with |
| | 8 | |
| | 9 | {{{ |
| | 10 | $ git reset --hard <commit-id> |
| | 11 | }}} |
| | 12 | |
| | 13 | Next build and test. If it still fails, move further back in history and retry, until you find a version that works. Optimally, you should bisecting at the middle of commits between ''known good'' and ''known bad'', then repeat the procedure until you pinpoint the bad commit. |
| | 14 | |
| | 15 | If you have hunch which commit might have introduced the bug, you can try reverting it to see what happens: |
| | 16 | |
| | 17 | {{{ |
| | 18 | git revert <commit-id> |
| | 19 | }}} |
| | 20 | |
| | 21 | In case no later commits conflict with the commit, this will work. If there are conflicts, fix them manually or abort the revert and write a reverting commit manually. |
