Home PC Games Linux Windows Database Network Programming Server Mobile  
           
  Home \ Linux \ Help you make Git Bisect     - Teach you self-built Linux firewall free (Linux)

- Java exception handling mechanism (Programming)

- Debian 7.8 system installation and configuration process (Linux)

- Linux System shutdown procedures (Linux)

- Java Foundation - The relationship between abstract classes and interfaces (Programming)

- OpenSIPS offline messaging feature set (Server)

- How UTorrent download the ISO image from the command line (Linux)

- Replace font under Linux (Linux)

- How to install Laravel PHP framework on CentOS 7 / Ubuntu 15.04 (Server)

- Summary of Docker mounted directory (Server)

- How to use Aptik to backup and restore Apps/PPAs under ubuntu (Linux)

- OpenStack package problems and solutions under CentOS6 (Linux)

- CentOS7 complete step to install Hadoop2.7 (Server)

- Java application server WildFly (Server)

- Debian 8 Jessie install LAMP server tutorial (Server)

- Linux port mapping system (routing and forwarding) (Server)

- Oracle 11g RAC manually playing GI PSU patch (11.2.0.4.8) (Database)

- RMAN parameters of ARCHIVELOG DELETION (Database)

- iTerm - let your command line can also be colorful (Linux)

- Iptables principle (Linux)

 
         
  Help you make Git Bisect
     
  Add Date : 2017-08-31      
         
         
         
  Git to provide a lot of tools to help us improve our work processes. bisect command is one of them, although not by much without the use of well-known, but when you want to know what is an otherwise good branches from the beginning to deteriorate, it could come in handy. In the end, which one submitted screwed up it, let bisect to tell you.

Bisect based binary search algorithm. Given an ordered sequence of elements, it will return you are looking for a number of elements (or tell you whether the element in the sequence). It is based on the same formula as follows: When you finish a contrast element, you can discard it out all the elements before or after the result of the comparison (and thus greatly narrowing the scope of the next lookup).

If you have been to the library, you may notice that the books within each zone are sorted by author name to. Let's say you're looking for a book author's last name is Martin, and you just see the last author of a book on the shelves of a last name beginning with F, then you can be sure you are looking for a certain book on the back of a shelf. This is the way to continue to the next, you can quickly narrow your search until you find the book you want so far.

Binary search is also true. If you want to have a sequence of n elements (ordered) to find the elements of x, you pick the first n / 2 elements and compares it with the element x. If x, then the sequence will be repeated from n / 2 + 1 to n of the above steps, on the contrary, repeat the above steps from 1 to n / 2-1 sub-sequences, this has been recursion. Here there is an interesting presentation on this algorithm.

Much less binary search algorithm required number of comparisons than you usually get silly sequence of each element in the comparison with x number of comparisons required. Facts have proved that find elements in an ordered sequence, the binary search faster and more useful.

Bisect

Bisect is to use a binary search to find it in your hair to a branch in the end is what commit introduced a specific change.

First, and most basic, you have to have a way to detect a given commit point is not a bug. Usually you can write test code, if this is not possible, then at least you have to have a set of steps to make the bug reproduced.

With this detection method, you can begin to use bisect to find your commit history to find the fastest time of the introduction of the bug. Wait, you have to be ready to submit two points: one is that you determine the bug has not yet been introduced commit point, the other is to determine the bug has been introduced to submit point (thus narrowing the initial search range). On bisect command, you can use the hash value (hash) or tag (tag) to refer to both commit point. When bisect Find, Look in the commit point is marked as either good (pass the test, bug-free), or be marked as bad (pass the test, there is a bug).

bisect the steps (green dot is good commit point, the red dot is bad): bisect be required to submit to a point within the range of 8 to find the bug was first introduced commit point (see Fig. 6 at a glance is the commit point), here submit two (a good one bad) points 1 and 8 is mentioned in the previous paragraph, we need to be ready to bisect command commit point. bisect detection method first used by the caller to submit 1-8 intermediate test point 4, if it is good (the case on the diagram), then bisect the area to narrow the scope of its right, repeat the steps above, on the contrary, the choose a region on its left for the new search. So recursion, in the example above, you only need three steps to determine the culprit is the commit point 6.

Here I created a git repository, which submitted a total of 1024 records, each submission is to the back of a text file to add an incremental number, from 1 to 1024, a digital line. Our task is to identify which points to submit a text file attached 1013 this figure (we assume that it is a bug).

First, we set a method to determine which files have this number. This is a test. The method is simple:

$ Grep 1013 file.txt

With this command, we can begin to bisect the:

$ Git bisect start

On the master branch (head commit point) to run this test, we did not get the results you want (that is, no output), so we mark it as bad.

$ Git bisect bad

Let us now specify a good commit point: Suppose first to submit a point (7c0dcfa) is not a bug. We checked out (check out) Submit this point and mark it as good commit point (git bisect good + the commit hash value of the point).

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

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

$ Git bisect start master 7c0dcfa

git bisect start command takes two arguments, the first one is bad commit point, the second point is a good submission.

Well, git bisect submitted automatically detected middle point, run our detection command, no output (no bug), so we submit that the point is marked as good.

$ Grep 1013 file.txt
 
$ Git bisect good
Bisecting: The remaining 255 amendments to be tested (probably also need to step 8)
[A01ba83f3500b48da97c5f5c33052623aaa4161a] added 768

$ Grep 1013 file.txt
 
$ Git bisect good
Bisecting: The remaining 255 amendments to be tested (probably also need to step 8)
[A01ba83f3500b48da97c5f5c33052623aaa4161a] added 768

Translator's Note: According to the binary search algorithm, bisect the results of your mark, the decision is detected in the middle of the left half of the commit point (if you are labeled as bad) or in the middle of the right half commit point (if you marked as good)

On bisect new detection commit point, we run the test command again. This is still a good commit point.

$ Grep 1013 file.txt
 
$ Git bisect good
Bisecting: The remaining 127 amendments to be tested (probably also need to step 7)
[4a4a668bf3363d09af5fd1906bc4272aacdb4495] added 896

Test again, still good commit point.

$ Grep 1013 file.txt
 
$ Git bisect good
Bisecting: The remaining 63 amendments to be tested (probably also need to step 6)
[9059c5b8b898159e8d1d797bff3b1febd1fd6a1c] added 960

Let's look at these messages: In addition to tell you the current submission of new detection points, and the new search range of the number of tests to be submitted to the point, but it is also up to you to estimate how many tests need to be repeated commands to find you to submit points. This submission is a good point.

$ Grep 1013 file.txt
 
$ Git bisect good
Bisecting: The remaining 31 amendments to be tested (probably also need to step 5)
[0c844d0b33ef297b742206ebc293f4925705b083] added 992

Continued, it is still a good commit point.

$ Grep 1013 file.txt
 
$ Git bisect good
Bisecting: The remaining 15 amendments to be tested (probably also need to step 4)
[0ee17eb17bd96b321a01c73eb13a8929a68b1239] added 1008

There are four steps, this is still good.

$ Grep 1013 file.txt
 
$ Git bisect good
Bisecting: The remaining seven amendments to be tested (probably also need to step 3)
[Dfb1e71736dcfffa2a30aecd7299f45f757c057e] added 1016

The test command finally output, bug coming out! We submit this point is marked as bad.

$ Grep 1013 file.txt
1013
$ Git bisect bad
Bisecting: The remaining three amendments to be tested (probably need 2 steps)
[6e6d08c374df5162fed65fed82859b69f86b936e] added 1012

End close, the test is passed, we mark it as good.

$ Grep 1013 file.txt
 
$ Git bisect bad
Bisecting: remaining a revision to be tested (probably also you need to step 1)
254efa859d7fc66f1f58a59f0] added 1014

Submit a bad point.

$ Grep 1013 file.txt
1013
$ Git bisect bad
Bisecting: 0 remaining amendments to be tested (probably also need to step 0)
8e16d98ec7039a7c53855dd9ed6] added 1013

The final step, this is bad.

$ Git bisect bad
458eab0eb8d808e16d98ec7039a7c53855dd9ed6 is the first bad commit
commit 458eab0eb8d808e16d98ec7039a7c53855dd9ed6
Author: Rodrigo Flores < mail@rodrigoflores.org>
Date: Tue Oct 21 22:31:05 2014 -0200

    added 1013

: 100644 100644 7bc3db7f48a43ccf1a8cc7c26146912cc88c1009 b393a2138a96c1530f41f70
1ab43cca893226976 M file.txt
We finally got the figures submitted by the introduction of 1013 points. Command git bisect log can replay the whole process.

$ Git bisect start
# Bad: [740cdf012013dc41a39b41d4b09b57a970bfe38f] added 1024
git bisect bad 740cdf012013dc41a39b41d4b09b57a970bfe38f
# Good: [7c0dcfa7514379151e0d83ffbf805850d2093538] added 1
git bisect good 7c0dcfa7514379151e0d83ffbf805850d2093538
# Good: [8950f7db7e7cad0b2dc394ff9b75fc3d38c9d72a] added 512
git bisect good 8950f7db7e7cad0b2dc394ff9b75fc3d38c9d72a
# Good: [a01ba83f3500b48da97c5f5c33052623aaa4161a] added 768
git bisect good a01ba83f3500b48da97c5f5c33052623aaa4161a
# Good: [4a4a668bf3363d09af5fd1906bc4272aacdb4495] added 896
git bisect good 4a4a668bf3363d09af5fd1906bc4272aacdb4495
# Good: [9059c5b8b898159e8d1d797bff3b1febd1fd6a1c] added 960
git bisect good 9059c5b8b898159e8d1d797bff3b1febd1fd6a1c
# Good: [0c844d0b33ef297b742206ebc293f4925705b083] added 992
git bisect good 0c844d0b33ef297b742206ebc293f4925705b083
# Good: [0ee17eb17bd96b321a01c73eb13a8929a68b1239] added 1008
git bisect good 0ee17eb17bd96b321a01c73eb13a8929a68b1239
# Bad: [dfb1e71736dcfffa2a30aecd7299f45f757c057e] added 1016
git bisect bad dfb1e71736dcfffa2a30aecd7299f45f757c057e
# Good: [6e6d08c374df5162fed65fed82859b69f86b936e] added 1012
git bisect good 6e6d08c374df5162fed65fed82859b69f86b936e
# Bad: [1d23b7045a8accd254efa859d7fc66f1f58a59f0] added 1014
git bisect bad 1d23b7045a8accd254efa859d7fc66f1f58a59f0
# Bad: [458eab0eb8d808e16d98ec7039a7c53855dd9ed6] added 1013
git bisect bad 458eab0eb8d808e16d98ec7039a7c53855dd9ed6
# First bad commit: [458eab0eb8d808e16d98ec7039a7c53855dd9ed6] added 1013
For this example, a total of 1024 points submitted, we traverse them only 10 steps. If you submit more than doubled the number of points into 2048, according to the binary search algorithm, we only need to pay more step to find the desired submit point, because binary search algorithm time complexity is O (log n).

Despite so efficient, over and over again to run the test command is very boring. So let us go further, we will automate this process.

automation

Git bisect can accept a script file name as a command parameter by which to judge the current return code commit point is good or bad. If it returns 0, is good commit point, the return value is the other bad commit point. Coincidentally, grep command If a matching row returns 0, otherwise it returns 1. You can use echo $? Command test command to check the return value.

grep return value and just opposite our testing standards, so we need to write a script to reverse its value (I'm not used to write shell scripts, if you have a better way, thanks to inform).

#! / Bin / sh
 
if [[ `grep 1013 file.txt`]]; then
  exit 1
else
  exit 0
fi

Save the above code test.sh, and give it execute permissions.

Next, in order to bisect the specified initial good / bad points after submission, 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] added 768
running ./ola.sh
Bisecting: 127 revisions left to test after this (roughly 7 steps)
[4a4a668bf3363d09af5fd1906bc4272aacdb4495] added 896
running ./ola.sh
Bisecting: 63 revisions left to test after this (roughly 6 steps)
[9059c5b8b898159e8d1d797bff3b1febd1fd6a1c] added 960
running ./ola.sh
Bisecting: 31 revisions left to test after this (roughly 5 steps)
[0c844d0b33ef297b742206ebc293f4925705b083] added 992
running ./ola.sh
Bisecting: 15 revisions left to test after this (roughly 4 steps)
[0ee17eb17bd96b321a01c73eb13a8929a68b1239] added 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] added 1012
running ./ola.sh
Bisecting: 1 revision left to test after this (roughly 1 step)
[1d23b7045a8accd254efa859d7fc66f1f58a59f0] added 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>
Date: Tue Oct 21 22:31:05 2014 -0200
 
    added 1013
 
: 100644 100644 7bc3db7f48a43ccf1a8cc7c26146912cc88c1009 b393a2138a96c15
30f41f701ab43cca893226976 M file.txt
bisect run success

Effortlessly, you get the problem submission points.

in conclusion

You probably will not have to use bisect each day. Maybe one week once, even used only once a month. But when you want to troubleshoot a problem into submission points, bisect really help you out. Although not necessary, control the scale of the changes each commit not too much will bisect the investigation helpful. If each submission contains a lot of changes, so even bisect help you find the commit, you have to wrapped up in a lot of changes in the hard search bug trail. Therefore, I recommend submission policy is too big too often.
     
         
         
         
  More:      
 
- How to Install Cantata MPD 1.3.3 for Ubuntu and Derived Version Users (Linux)
- CentOS installation Percona Server 5.5.42 compiling problem solve one case (Linux)
- Linux iostat command example explanation (Linux)
- Python system default encoding (Programming)
- RHEL5 establish a local yum source (Linux)
- MySQL fuzzy query: LIKE and REGEXP pattern mode (Database)
- Build Nginx + uWSGI + Flask operating environment under CentOS 6.4 tutorial (Server)
- Error: Unable to establish connection with FTP SFTP server (Server)
- Gentoo: !!! existing preserved libs problem (Linux)
- C # dynamic class notes --- (Dynamic) Applications (Programming)
- RedHat / CentOS ext4 partition can not be formatted large supplementary ext4 formatting (Linux)
- Some common regular expressions (Linux)
- Use Observium to monitor your network and servers (Server)
- Compression decompression command under Linux (Linux)
- C ++ handling text input (Programming)
- Httpclient4.4 of principle (Http execution context) (Programming)
- CentOS 6.6 shortcut command execution (Linux)
- Ubuntu 32 compile Android 4.0.4 Problems (Linux)
- How to configure security services under Linux (Linux)
- Linux operating system ARP Spoofing Defense (Linux)
     
           
     
  CopyRight 2002-2022 newfreesoft.com, All Rights Reserved.