Let Git Bisect help you

Let Git Bisect help you

Git provides many tools to help us improve our workflow. The bisect command is one of them. Although it is not widely used, it can be used when you want to know when a good branch will deteriorate. Which commit has screwed up? Let bisect tell you.

Bisect is based on the binary search algorithm. Given an ordered element sequence, it returns the sequence number of the element you want to search for (or tells you whether the element is in the sequence ). It is based on the following non-variant formula: When you compare an element, You can discard all the elements before or after it based on the comparison results (thus greatly narrowing down the scope of the next search ).

If you have been to the library, you may notice that the books in each area are sorted by the author's name. For example, the author of the book you are looking for is Martin, and you just saw that the author of the last book on a shelf started with F, then you can be sure that the book you are looking for must be placed on a shelf in the back. Next time, you can quickly narrow down the search scope until you find the book you want.

The same is true for Binary lookup. If you want to search for element x in the sequence of n elements (ordered), you can pick out element n/2 and compare it with element x. If x is large, repeat the preceding steps for subsequences from n/2 + 1 to n. Otherwise, repeat the above steps for subsequences from 1 to n/2-1, so that the recursion continues. Here is an interesting demonstration of this algorithm.

The comparison times required by the binary search algorithm are usually less than the number of times you need to compare each element in the sequence with x. It turns out that searching for elements in an ordered sequence is faster and more useful.

Bisect

Bisect uses binary lookup to find out which commit has introduced a specific change in one of your branches.

First, it is also the minimum. You have to find a way to check whether a given submission point has a bug. Generally, you can write a test code. If this is not possible, you need at least a set of steps to reproduce the bug.

With this detection method, you can start to use bisect to search for your submission history to find the time point for introducing bugs as quickly as possible. Wait, you have to prepare two Submission points: one is the one that you are sure the bug has not been introduced, the other is to determine the submitted point introduced by the bug (this reduces the initial search range ). On the bisect command, you can use hash or tag to reference the two commit points. During bisect search, the submission points in the search range are either marked as good (tested, without Bugs) or marked as bad (not tested, with bugs ).

Demonstrate the execution steps of bisect (the green dot is a good commit point, and the red dot is a bad one ): bisect is required to search for the Submission point of the first introduced bug within the range of the submission point 1 to 8 (see Figure 6 at a Glance). Here the submission points 1 and 8 are mentioned in the previous section, we need to first prepare two (good, bad) Commit points for the bisect command. Bisect first uses the detection method provided by the caller to test the commit point 4 between 1 and 8. If it is good (as shown in the figure), bisect will narrow down the area to the right of the caller, repeat the preceding steps. Otherwise, select the new search range in the area on the left. In this example, only three steps are required to determine that the culprit is commit point 6.

I have created a git repository with a total of 1024 commit records. Each commit adds an incremental number, from 1 to 1024, to the end of a text file. Our task is to find out which submission point has attached the number 1013 to the text file (we assume it is a bug ).

First, let's determine whether there is a number in the file. This is a test. The method is simple:

$ Grep 1013 file.txt

With this command, we can start bisect:

$ Git bisect start

Run this test on the master branch (the header commit point) without getting the desired result (that is, there is no output), so we mark it as bad.

$ Git bisect bad

Now let's specify a good commit point: assume that the first commit point (7c0dcfa) has no bug. We can check out the commit point and mark it as a good commit point (git bisect good + hash value of this commit point ).

$ Git bisect good 7c0dcfa
Bisecting: 511 revisions left to test after this (roughly 9 steps)
[8950f7db7e7cad0b2dc394ff9b75fc3d38c9d72a] addded 512

You can also use the following command to complete all the above steps:

$ Git bisect start master 7c0dcfa

The git bisect start command can accept two parameters. The first is a bad commit point, and the second is a good commit point.

Good. git bisect automatically detects the commit point in the middle and runs our detection command without any output (no bug). Therefore, we can mark the commit point as good.

$ Grep 1013 file.txt
 
$ Git bisect good
Bisecting: remaining 255 revisions to be tested (about 8 more steps required)
[A01ba83f3500b48da97c5f5c33052623aaa4161a] addded 768

$ Grep 1013 file.txt
 
$ Git bisect good
Bisecting: remaining 255 revisions to be tested (about 8 more steps required)
[A01ba83f3500b48da97c5f5c33052623aaa4161a] addded 768

Note: Based on the binary search algorithm, bisect determines the intermediate commit point for detecting the left half side (if you mark it as bad) based on the result you mark) or the middle commit point of the right half side (if you mark it as good)

On the submit point of the new bisect check-out, run the test command again. This is still a good submission point.

$ Grep 1013 file.txt
 
$ Git bisect good
Bisecting: The remaining 127 revisions to be tested (about 7 more steps required)
[4a4a668bf3363d09af5fd1906bc4272aacdb4495] addded 896

Check again, or click submit again.

$ Grep 1013 file.txt
 
$ Git bisect good
Bisecting: 63 remaining revisions to be tested (about 6 more steps required)
[9059c5b8b898159e8d1d797bff3b1febd1fd6a1c] addded 960

Let's take a look at these messages: In addition to telling you the submission points for the new check-out and the number of Submission points to be tested in the new search range, it also estimates the maximum number of times you need to repeat the test command to find the submission point you want. This is another good submission point.

$ Grep 1013 file.txt
 
$ Git bisect good
Bisecting: 31 remaining revisions to be tested (5 more steps required)
[0c844d0b33ef297b742206ebc293fda-705b083] added 992

Continue, it is still a good submission point.

$ Grep 1013 file.txt
 
$ Git bisect good
Bisecting: 15 remaining revisions to be tested (about 4 more steps required)
[0ee17eb17bd96b321a01c73eb13a8929a68b1239] addded 1008

There are still four steps. This time it is still good.

$ Grep 1013 file.txt
 
$ Git bisect good
Bisecting: the remaining 7 revisions to be tested (about three more steps are required)
[Dfb1e71736dcfffa2a30aecd7299f45f757c057e] added 1016

The test command has finally been output, and the bug has appeared! We marked this commit point as bad.

$ Grep 1013 file.txt
1013
$ Git bisect bad
Bisecting: three remaining revisions to be tested (about two more steps required)
[6e6d08c374df5162fed65fed82859b69f86b936e] addded 1012

The end point is close at hand and passes the test. We can mark it as good.

$ Grep 1013 file.txt
 
$ Git bisect bad
Bisecting: one remaining revision to be tested (about one more step)
254efa859d7fc66f1f58a59f0] addded 1014

Bad commit point.

$ Grep 1013 file.txt
1013
$ Git bisect bad
Bisecting: 0 remaining revisions to be tested (about 0 more steps required)
8e16d98ec7039a7c53855dd9ed6] addded 1013

The last step is bad.

$ git bisect bad 458eab0eb8d808e16d98ec7039a7c53855dd9ed6 is the first bad commitcommit 458eab0eb8d808e16d98ec7039a7c53855dd9ed6Author: Rodrigo Flores <mail@rodrigoflores.org>Date:   Tue Oct 21 22:31:05 2014 -0200    added 1013:100644 100644 7bc3db7f48a43ccf1a8cc7c26146912cc88c1009 b393a2138a96c1530f41f701ab43cca893226976 M  file.txt

We finally got the commit point that introduced 1013 numbers. The command git bisect log can play back the entire process.

$ git bisect start # bad: [740cdf012013dc41a39b41d4b09b57a970bfe38f] added 1024git bisect bad 740cdf012013dc41a39b41d4b09b57a970bfe38f# good: [7c0dcfa7514379151e0d83ffbf805850d2093538] added 1git bisect good 7c0dcfa7514379151e0d83ffbf805850d2093538# good: [8950f7db7e7cad0b2dc394ff9b75fc3d38c9d72a] added 512git bisect good 8950f7db7e7cad0b2dc394ff9b75fc3d38c9d72a# good: [a01ba83f3500b48da97c5f5c33052623aaa4161a] added 768git bisect good a01ba83f3500b48da97c5f5c33052623aaa4161a# good: [4a4a668bf3363d09af5fd1906bc4272aacdb4495] added 896git bisect good 4a4a668bf3363d09af5fd1906bc4272aacdb4495# good: [9059c5b8b898159e8d1d797bff3b1febd1fd6a1c] added 960git bisect good 9059c5b8b898159e8d1d797bff3b1febd1fd6a1c# good: [0c844d0b33ef297b742206ebc293f4925705b083] added 992git bisect good 0c844d0b33ef297b742206ebc293f4925705b083# good: [0ee17eb17bd96b321a01c73eb13a8929a68b1239] added 1008git bisect good 0ee17eb17bd96b321a01c73eb13a8929a68b1239# bad: [dfb1e71736dcfffa2a30aecd7299f45f757c057e] added 1016git bisect bad dfb1e71736dcfffa2a30aecd7299f45f757c057e# good: [6e6d08c374df5162fed65fed82859b69f86b936e] added 1012git bisect good 6e6d08c374df5162fed65fed82859b69f86b936e# bad: [1d23b7045a8accd254efa859d7fc66f1f58a59f0] added 1014git bisect bad 1d23b7045a8accd254efa859d7fc66f1f58a59f0# bad: [458eab0eb8d808e16d98ec7039a7c53855dd9ed6] added 1013git bisect bad 458eab0eb8d808e16d98ec7039a7c53855dd9ed6# first bad commit: [458eab0eb8d808e16d98ec7039a7c53855dd9ed6] added 1013

In this example, there are a total of 1024 commit points, and we only use 10 steps to traverse them. If the number of submitted points is doubled to 2048, we only need to add one more step to find the desired submitted point based on the binary search algorithm, because the time complexity of the binary search algorithm is O (log n ).

Despite its high efficiency, running test commands over and over again is still boring. Therefore, let's further automate this process.

Automation

Git bisect can take a script file name as a command parameter and use its return code to determine whether the current commit point is good or bad. If 0 is returned, it is a good commit point. If other values are returned, it is a bad commit point. Coincidentally, if the grep Command finds a matching line, 0 is returned, and 1 is returned. You can use echo $? Command to check the return value of the test command.

The return value of grep is exactly the opposite of our test standard, so we need to write a script to reverse its value (I am not used to writing shell scripts, if you have a better way, thanks ).

#! /Bin/sh
 
If [['grep 1013 file.txt ']; then
Exit 1
Else
Exit 0
Fi

Save the preceding code as test. sh and grant it the execution permission.

After specifying the initial good/bad commit point for the bisect command, you only need to run:

Git bisect run./test. sh
Running./ola. sh
Bisecting: 255 revisions left to test after this (roughly 8 steps)
[A01ba83f3500b48da97c5f5c33052623aaa4161a] addded 768
Running./ola. sh
Bisecting: 127 revisions left to test after this (roughly 7 steps)
[4a4a668bf3363d09af5fd1906bc4272aacdb4495] addded 896
Running./ola. sh
Bisecting: 63 revisions left to test after this (roughly 6 steps)
[9059c5b8b898159e8d1d797bff3b1febd1fd6a1c] addded 960
Running./ola. sh
Bisecting: 31 revisions left to test after this (roughly 5 steps)
[0c844d0b33ef297b742206ebc293fda-705b083] added 992
Running./ola. sh
Bisecting: 15 revisions left to test after this (roughly 4 steps)
[0ee17eb17bd96b321a01c73eb13a8929a68b1239] addded 1008
Running./ola. sh
Bisecting: 7 revisions left to test after this (roughly 3 steps)
[Dfb1e71736dcfffa2a30aecd7299f45f757c057e] added 1016
Running./ola. sh
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[6e6d08c374df5162fed65fed82859b69f86b936e] addded 1012
Running./ola. sh
Bisecting: 1 revision left to test after this (roughly 1 step)
[1d23b7045a8accd254efa859d7fc66f1f58a59f0] addded 1014
Running./ola. sh
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[458eab0eb8d808e16d98ec7039a7c53855dd9ed6] added 1013
Running./ola. sh
458eab0eb8d808e16d98ec7039a7c53855dd9ed6 is the first bad commit
Commit 458eab0eb8d808e16d98ec7039a7c53855dd9ed6
Author: Rodrigo Flores <mail@rodrigoflores.org>
Time: Tue Oct 21 22:31:05 2014-0200
 
Addded 1013
 
: 100644 100644 7bc3db7f48a43ccf1a8cc7c26146912cc88c1009 b393a2138a96c15
30f41f701ab43cca893226976 M file.txt
Bisect run success

With no effort, you will get a problem submission point.

Conclusion

You probably won't use bisect every day. It may be used once a week or even once a month. But when you want to locate the submission points that bring in the problem, bisect does help you. Although not necessary, controlling the scale of changes submitted each time should not be too large for bisect's troubleshooting. If each submission contains a large number of changes, even if bisect helps you find the submission, you have to bury yourself in a lot of changes to search for bugs. Therefore, I recommend too many submission policies.

What about you? Do you often use bisect?

Linux git command parameters and Usage Details

Fedora downloads Git through Http Proxy

Install Git on Ubuntu Server

Create a Git repository on the server (Ubuntu)

Git simple tutorial in Linux (taking Android as an example)

Git authoritative guide PDF

Git 2-minute Guide

Git details: click here
Git: click here

This article permanently updates the link address: