Bisect
A bisect finds the first commit where a bug exists. You give Git a commit where the bug exists and an earlier commit where it does not. Git checks out a commit between them and asks you to test it. Each answer halves what is left, so a few tests cover hundreds of commits.
The Bisect tab shows the search: the range it covers, every decision, and the result with what it means. The Project Header carries the controls while the search runs.
Start a bisect
In Commits, right-click a commit where the bug exists. Click Bisect, then Select Bad Commit. The Bisect tab opens with the bisect control, because they are one operation. Go back to Commits to select the other commit, or to change this one. A good commit is selected for you: the most recent tag in that commit’s history, or a commit further back. To choose it yourself, right-click an earlier commit and click Select Good Commit.
When tagged commits have the same date and time, Zide prefers the later one in their shared history. Check the good commit before you start. A bisect trusts it, so if the bug also exists there, the search ends on the wrong commit and reports no error.
The Project Header shows Bisect: Ready. Click Start there, or Start Bisect in the Bisect tab. Git checks out the first commit to test, and the tab comes to the front to follow the search. Cancel Bisect drops the commits and closes the tab.
A bisect always runs between two commits you select. To bisect between releases, find each tagged commit in Commits and select it there.
Test and mark
Git checks the commit out for you, so you do not have to. Test it, then click Good or Bad on the Project Header, or Mark as Good or Mark as Bad in the Bisect tab.
- Good means the bug does not exist in this commit.
- Bad means the bug exists in this commit.
If you cannot test a commit, open the Bisect menu and click Skip. Git tries a nearby commit instead. Skipped commits can leave more than one possible answer.
Every commit in the search is marked in the Commits list. The row takes a colour and names its state: Bad, Good, Testing, Skipped, or First Bad. A line at the left edge of the rows shows the part of the history Git is still searching. Each Commit tab carries a bar that says what that commit is to the search.
While a bisect runs, Zide disables amend, revert, cherry-pick, reset, and checking out a branch or a commit until the bisect ends.
If the next test commit is not checked out, the Project Header shows Bisect: Blocked. This can happen after a failed checkout or if you switch branches in a terminal. Resolve any changes that prevent checkout, then click Retry Checkout in the Project Header’s bisect menu to resume testing. To end the search instead, click Abort Bisect… and confirm. Git returns to the starting branch or commit and discards the bisect decisions.
Read the result
When one commit is left, the Project Header shows Bisect: Found, and the Bisect tab shows the answer. Click Finish Bisect to end the search and return to where it started. The tab explains the answer: this is the oldest commit where the bug exists, so the change that introduced it is here.
Click a commit in the tab to open it. Click its Good commit or Bad commit badge to find it in Commits, where the search is drawn in history order. In Commits, the state of each commit is at the end of its row, and the row takes the color of that state. The Commit view says the same thing in its BISECT banner, which also holds the actions for that commit.
Skipped commits can prevent a single answer. The tab then lists every commit that could be the first bad one.
The search is cleared from Commits, and the result stays in the Bisect tab. Click Close in the tab when you are done with the answer, which discards it and closes the tab. Closing the tab by its own close button only closes the view; Show Bisect brings the result back.
Click Abort Bisect… at any time to end the search without a result. Git returns to where the bisect started, and the decisions are discarded.
Open the tab again
Click Show Bisect in the Project Header’s bisect menu. The tab holds one search per repository.
Press Escape while the header menu has focus to close it and return focus to the Bisect: label. This works before starting, during testing, and when the result is shown.
Under Log, the tab lists what Git recorded, in the order it recorded it.
If you mark a commit wrongly, click Undo Last Decision, in the Log menu or in the bisect control’s own menu. Zide takes the decision back and Git works out the next commit to test from the ones that are left. You can click it more than once, back to the two commits you started with.
The Log menu also holds Copy Git’s Log, which puts Git’s own copy of those rows on the clipboard. That is what git bisect replay takes.
A bisect started somewhere else
Zide reads a bisect started in a terminal, including one that uses a pathspec or its own terms for good and bad. The controls, the tab, and the Commits list describe it the same way. If Git has only one of the two commits, the Project Header asks for the other one.