diff options
Diffstat (limited to 'third_party/git/Documentation/git-bisect-lk2009.txt')
| -rw-r--r-- | third_party/git/Documentation/git-bisect-lk2009.txt | 1358 |
1 files changed, 0 insertions, 1358 deletions
diff --git a/third_party/git/Documentation/git-bisect-lk2009.txt b/third_party/git/Documentation/git-bisect-lk2009.txt deleted file mode 100644 index f3d9566c8988..000000000000 --- a/third_party/git/Documentation/git-bisect-lk2009.txt +++ /dev/null @@ -1,1358 +0,0 @@ -Fighting regressions with git bisect -==================================== -:Author: Christian Couder -:Email: chriscool@tuxfamily.org -:Date: 2009/11/08 - -Abstract --------- - -"git bisect" enables software users and developers to easily find the -commit that introduced a regression. We show why it is important to -have good tools to fight regressions. We describe how "git bisect" -works from the outside and the algorithms it uses inside. Then we -explain how to take advantage of "git bisect" to improve current -practices. And we discuss how "git bisect" could improve in the -future. - - -Introduction to "git bisect" ----------------------------- - -Git is a Distributed Version Control system (DVCS) created by Linus -Torvalds and maintained by Junio Hamano. - -In Git like in many other Version Control Systems (VCS), the different -states of the data that is managed by the system are called -commits. And, as VCS are mostly used to manage software source code, -sometimes "interesting" changes of behavior in the software are -introduced in some commits. - -In fact people are specially interested in commits that introduce a -"bad" behavior, called a bug or a regression. They are interested in -these commits because a commit (hopefully) contains a very small set -of source code changes. And it's much easier to understand and -properly fix a problem when you only need to check a very small set of -changes, than when you don't know where look in the first place. - -So to help people find commits that introduce a "bad" behavior, the -"git bisect" set of commands was invented. And it follows of course -that in "git bisect" parlance, commits where the "interesting -behavior" is present are called "bad" commits, while other commits are -called "good" commits. And a commit that introduce the behavior we are -interested in is called a "first bad commit". Note that there could be -more than one "first bad commit" in the commit space we are searching. - -So "git bisect" is designed to help find a "first bad commit". And to -be as efficient as possible, it tries to perform a binary search. - - -Fighting regressions overview ------------------------------ - -Regressions: a big problem -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Regressions are a big problem in the software industry. But it's -difficult to put some real numbers behind that claim. - -There are some numbers about bugs in general, like a NIST study in -2002 <<1>> that said: - -_____________ -Software bugs, or errors, are so prevalent and so detrimental that -they cost the U.S. economy an estimated $59.5 billion annually, or -about 0.6 percent of the gross domestic product, according to a newly -released study commissioned by the Department of Commerce's National -Institute of Standards and Technology (NIST). At the national level, -over half of the costs are borne by software users and the remainder -by software developers/vendors. The study also found that, although -all errors cannot be removed, more than a third of these costs, or an -estimated $22.2 billion, could be eliminated by an improved testing -infrastructure that enables earlier and more effective identification -and removal of software defects. These are the savings associated with -finding an increased percentage (but not 100 percent) of errors closer -to the development stages in which they are introduced. Currently, -over half of all errors are not found until "downstream" in the -development process or during post-sale software use. -_____________ - -And then: - -_____________ -Software developers already spend approximately 80 percent of -development costs on identifying and correcting defects, and yet few -products of any type other than software are shipped with such high -levels of errors. -_____________ - -Eventually the conclusion started with: - -_____________ -The path to higher software quality is significantly improved software -testing. -_____________ - -There are other estimates saying that 80% of the cost related to -software is about maintenance <<2>>. - -Though, according to Wikipedia <<3>>: - -_____________ -A common perception of maintenance is that it is merely fixing -bugs. However, studies and surveys over the years have indicated that -the majority, over 80%, of the maintenance effort is used for -non-corrective actions (Pigosky 1997). This perception is perpetuated -by users submitting problem reports that in reality are functionality -enhancements to the system. -_____________ - -But we can guess that improving on existing software is very costly -because you have to watch out for regressions. At least this would -make the above studies consistent among themselves. - -Of course some kind of software is developed, then used during some -time without being improved on much, and then finally thrown away. In -this case, of course, regressions may not be a big problem. But on the -other hand, there is a lot of big software that is continually -developed and maintained during years or even tens of years by a lot -of people. And as there are often many people who depend (sometimes -critically) on such software, regressions are a really big problem. - -One such software is the Linux kernel. And if we look at the Linux -kernel, we can see that a lot of time and effort is spent to fight -regressions. The release cycle start with a 2 weeks long merge -window. Then the first release candidate (rc) version is tagged. And -after that about 7 or 8 more rc versions will appear with around one -week between each of them, before the final release. - -The time between the first rc release and the final release is -supposed to be used to test rc versions and fight bugs and especially -regressions. And this time is more than 80% of the release cycle -time. But this is not the end of the fight yet, as of course it -continues after the release. - -And then this is what Ingo Molnar (a well known Linux kernel -developer) says about his use of git bisect: - -_____________ -I most actively use it during the merge window (when a lot of trees -get merged upstream and when the influx of bugs is the highest) - and -yes, there have been cases that i used it multiple times a day. My -average is roughly once a day. -_____________ - -So regressions are fought all the time by developers, and indeed it is -well known that bugs should be fixed as soon as possible, so as soon -as they are found. That's why it is interesting to have good tools for -this purpose. - -Other tools to fight regressions -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -So what are the tools used to fight regressions? They are nearly the -same as those used to fight regular bugs. The only specific tools are -test suites and tools similar as "git bisect". - -Test suites are very nice. But when they are used alone, they are -supposed to be used so that all the tests are checked after each -commit. This means that they are not very efficient, because many -tests are run for no interesting result, and they suffer from -combinatorial explosion. - -In fact the problem is that big software often has many different -configuration options and that each test case should pass for each -configuration after each commit. So if you have for each release: N -configurations, M commits and T test cases, you should perform: - -------------- -N * M * T tests -------------- - -where N, M and T are all growing with the size your software. - -So very soon it will not be possible to completely test everything. - -And if some bugs slip through your test suite, then you can add a test -to your test suite. But if you want to use your new improved test -suite to find where the bug slipped in, then you will either have to -emulate a bisection process or you will perhaps bluntly test each -commit backward starting from the "bad" commit you have which may be -very wasteful. - -"git bisect" overview ---------------------- - -Starting a bisection -~~~~~~~~~~~~~~~~~~~~ - -The first "git bisect" subcommand to use is "git bisect start" to -start the search. Then bounds must be set to limit the commit -space. This is done usually by giving one "bad" and at least one -"good" commit. They can be passed in the initial call to "git bisect -start" like this: - -------------- -$ git bisect start [BAD [GOOD...]] -------------- - -or they can be set using: - -------------- -$ git bisect bad [COMMIT] -------------- - -and: - -------------- -$ git bisect good [COMMIT...] -------------- - -where BAD, GOOD and COMMIT are all names that can be resolved to a -commit. - -Then "git bisect" will checkout a commit of its choosing and ask the -user to test it, like this: - -------------- -$ git bisect start v2.6.27 v2.6.25 -Bisecting: 10928 revisions left to test after this (roughly 14 steps) -[2ec65f8b89ea003c27ff7723525a2ee335a2b393] x86: clean up using max_low_pfn on 32-bit -------------- - -Note that the example that we will use is really a toy example, we -will be looking for the first commit that has a version like -"2.6.26-something", that is the commit that has a "SUBLEVEL = 26" line -in the top level Makefile. This is a toy example because there are -better ways to find this commit with Git than using "git bisect" (for -example "git blame" or "git log -S<string>"). - -Driving a bisection manually -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -At this point there are basically 2 ways to drive the search. It can -be driven manually by the user or it can be driven automatically by a -script or a command. - -If the user is driving it, then at each step of the search, the user -will have to test the current commit and say if it is "good" or "bad" -using the "git bisect good" or "git bisect bad" commands respectively -that have been described above. For example: - -------------- -$ git bisect bad -Bisecting: 5480 revisions left to test after this (roughly 13 steps) -[66c0b394f08fd89236515c1c84485ea712a157be] KVM: kill file->f_count abuse in kvm -------------- - -And after a few more steps like that, "git bisect" will eventually -find a first bad commit: - -------------- -$ git bisect bad -2ddcca36c8bcfa251724fe342c8327451988be0d is the first bad commit -commit 2ddcca36c8bcfa251724fe342c8327451988be0d -Author: Linus Torvalds <torvalds@linux-foundation.org> -Date: Sat May 3 11:59:44 2008 -0700 - - Linux 2.6.26-rc1 - -:100644 100644 5cf82581... 4492984e... M Makefile -------------- - -At this point we can see what the commit does, check it out (if it's -not already checked out) or tinker with it, for example: - -------------- -$ git show HEAD -commit 2ddcca36c8bcfa251724fe342c8327451988be0d -Author: Linus Torvalds <torvalds@linux-foundation.org> -Date: Sat May 3 11:59:44 2008 -0700 - - Linux 2.6.26-rc1 - -diff --git a/Makefile b/Makefile -index 5cf8258..4492984 100644 ---- a/Makefile -+++ b/Makefile -@@ -1,7 +1,7 @@ - VERSION = 2 - PATCHLEVEL = 6 --SUBLEVEL = 25 --EXTRAVERSION = -+SUBLEVEL = 26 -+EXTRAVERSION = -rc1 - NAME = Funky Weasel is Jiggy wit it - - # *DOCUMENTATION* -------------- - -And when we are finished we can use "git bisect reset" to go back to -the branch we were in before we started bisecting: - -------------- -$ git bisect reset -Checking out files: 100% (21549/21549), done. -Previous HEAD position was 2ddcca3... Linux 2.6.26-rc1 -Switched to branch 'master' -------------- - -Driving a bisection automatically -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The other way to drive the bisection process is to tell "git bisect" -to launch a script or command at each bisection step to know if the -current commit is "good" or "bad". To do that, we use the "git bisect -run" command. For example: - -------------- -$ git bisect start v2.6.27 v2.6.25 -Bisecting: 10928 revisions left to test after this (roughly 14 steps) -[2ec65f8b89ea003c27ff7723525a2ee335a2b393] x86: clean up using max_low_pfn on 32-bit -$ -$ git bisect run grep '^SUBLEVEL = 25' Makefile -running grep ^SUBLEVEL = 25 Makefile -Bisecting: 5480 revisions left to test after this (roughly 13 steps) -[66c0b394f08fd89236515c1c84485ea712a157be] KVM: kill file->f_count abuse in kvm -running grep ^SUBLEVEL = 25 Makefile -SUBLEVEL = 25 -Bisecting: 2740 revisions left to test after this (roughly 12 steps) -[671294719628f1671faefd4882764886f8ad08cb] V4L/DVB(7879): Adding cx18 Support for mxl5005s -... -... -running grep ^SUBLEVEL = 25 Makefile -Bisecting: 0 revisions left to test after this (roughly 0 steps) -[2ddcca36c8bcfa251724fe342c8327451988be0d] Linux 2.6.26-rc1 -running grep ^SUBLEVEL = 25 Makefile -2ddcca36c8bcfa251724fe342c8327451988be0d is the first bad commit -commit 2ddcca36c8bcfa251724fe342c8327451988be0d -Author: Linus Torvalds <torvalds@linux-foundation.org> -Date: Sat May 3 11:59:44 2008 -0700 - - Linux 2.6.26-rc1 - -:100644 100644 5cf82581... 4492984e... M Makefile -bisect run success -------------- - -In this example, we passed "grep '^SUBLEVEL = 25' Makefile" as -parameter to "git bisect run". This means that at each step, the grep -command we passed will be launched. And if it exits with code 0 (that -means success) then git bisect will mark the current state as -"good". If it exits with code 1 (or any code between 1 and 127 -included, except the special code 125), then the current state will be -marked as "bad". - -Exit code between 128 and 255 are special to "git bisect run". They -make it stop immediately the bisection process. This is useful for -example if the command passed takes too long to complete, because you -can kill it with a signal and it will stop the bisection process. - -It can also be useful in scripts passed to "git bisect run" to "exit -255" if some very abnormal situation is detected. - -Avoiding untestable commits -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Sometimes it happens that the current state cannot be tested, for -example if it does not compile because there was a bug preventing it -at that time. This is what the special exit code 125 is for. It tells -"git bisect run" that the current commit should be marked as -untestable and that another one should be chosen and checked out. - -If the bisection process is driven manually, you can use "git bisect -skip" to do the same thing. (In fact the special exit code 125 makes -"git bisect run" use "git bisect skip" in the background.) - -Or if you want more control, you can inspect the current state using -for example "git bisect visualize". It will launch gitk (or "git log" -if the `DISPLAY` environment variable is not set) to help you find a -better bisection point. - -Either way, if you have a string of untestable commits, it might -happen that the regression you are looking for has been introduced by -one of these untestable commits. In this case it's not possible to -tell for sure which commit introduced the regression. - -So if you used "git bisect skip" (or the run script exited with -special code 125) you could get a result like this: - -------------- -There are only 'skip'ped commits left to test. -The first bad commit could be any of: -15722f2fa328eaba97022898a305ffc8172db6b1 -78e86cf3e850bd755bb71831f42e200626fbd1e0 -e15b73ad3db9b48d7d1ade32f8cd23a751fe0ace -070eab2303024706f2924822bfec8b9847e4ac1b -We cannot bisect more! -------------- - -Saving a log and replaying it -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -If you want to show other people your bisection process, you can get a -log using for example: - -------------- -$ git bisect log > bisect_log.txt -------------- - -And it is possible to replay it using: - -------------- -$ git bisect replay bisect_log.txt -------------- - - -"git bisect" details --------------------- - -Bisection algorithm -~~~~~~~~~~~~~~~~~~~ - -As the Git commits form a directed acyclic graph (DAG), finding the -best bisection commit to test at each step is not so simple. Anyway -Linus found and implemented a "truly stupid" algorithm, later improved -by Junio Hamano, that works quite well. - -So the algorithm used by "git bisect" to find the best bisection -commit when there are no skipped commits is the following: - -1) keep only the commits that: - -a) are ancestor of the "bad" commit (including the "bad" commit itself), -b) are not ancestor of a "good" commit (excluding the "good" commits). - -This means that we get rid of the uninteresting commits in the DAG. - -For example if we start with a graph like this: - -------------- -G-Y-G-W-W-W-X-X-X-X - \ / - W-W-B - / -Y---G-W---W - \ / \ -Y-Y X-X-X-X - --> time goes this way -> -------------- - -where B is the "bad" commit, "G" are "good" commits and W, X, and Y -are other commits, we will get the following graph after this first -step: - -------------- -W-W-W - \ - W-W-B - / -W---W -------------- - -So only the W and B commits will be kept. Because commits X and Y will -have been removed by rules a) and b) respectively, and because commits -G are removed by rule b) too. - -Note for Git users, that it is equivalent as keeping only the commit -given by: - -------------- -git rev-list BAD --not GOOD1 GOOD2... -------------- - -Also note that we don't require the commits that are kept to be -descendants of a "good" commit. So in the following example, commits W -and Z will be kept: - -------------- -G-W-W-W-B - / -Z-Z -------------- - -2) starting from the "good" ends of the graph, associate to each - commit the number of ancestors it has plus one - -For example with the following graph where H is the "bad" commit and A -and D are some parents of some "good" commits: - -------------- -A-B-C - \ - F-G-H - / -D---E -------------- - -this will give: - -------------- -1 2 3 -A-B-C - \6 7 8 - F-G-H -1 2/ -D---E -------------- - -3) associate to each commit: min(X, N - X) - -where X is the value associated to the commit in step 2) and N is the -total number of commits in the graph. - -In the above example we have N = 8, so this will give: - -------------- -1 2 3 -A-B-C - \2 1 0 - F-G-H -1 2/ -D---E -------------- - -4) the best bisection point is the commit with the highest associated - number - -So in the above example the best bisection point is commit C. - -5) note that some shortcuts are implemented to speed up the algorithm - -As we know N from the beginning, we know that min(X, N - X) can't be -greater than N/2. So during steps 2) and 3), if we would associate N/2 -to a commit, then we know this is the best bisection point. So in this -case we can just stop processing any other commit and return the -current commit. - -Bisection algorithm debugging -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -For any commit graph, you can see the number associated with each -commit using "git rev-list --bisect-all". - -For example, for the above graph, a command like: - -------------- -$ git rev-list --bisect-all BAD --not GOOD1 GOOD2 -------------- - -would output something like: - -------------- -e15b73ad3db9b48d7d1ade32f8cd23a751fe0ace (dist=3) -15722f2fa328eaba97022898a305ffc8172db6b1 (dist=2) -78e86cf3e850bd755bb71831f42e200626fbd1e0 (dist=2) -a1939d9a142de972094af4dde9a544e577ddef0e (dist=2) -070eab2303024706f2924822bfec8b9847e4ac1b (dist=1) -a3864d4f32a3bf5ed177ddef598490a08760b70d (dist=1) -a41baa717dd74f1180abf55e9341bc7a0bb9d556 (dist=1) -9e622a6dad403b71c40979743bb9d5be17b16bd6 (dist=0) -------------- - -Bisection algorithm discussed -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -First let's define "best bisection point". We will say that a commit X -is a best bisection point or a best bisection commit if knowing its -state ("good" or "bad") gives as much information as possible whether -the state of the commit happens to be "good" or "bad". - -This means that the best bisection commits are the commits where the -following function is maximum: - -------------- -f(X) = min(information_if_good(X), information_if_bad(X)) -------------- - -where information_if_good(X) is the information we get if X is good -and information_if_bad(X) is the information we get if X is bad. - -Now we will suppose that there is only one "first bad commit". This -means that all its descendants are "bad" and all the other commits are -"good". And we will suppose that all commits have an equal probability -of being good or bad, or of being the first bad commit, so knowing the -state of c commits gives always the same amount of information -wherever these c commits are on the graph and whatever c is. (So we -suppose that these commits being for example on a branch or near a -good or a bad commit does not give more or less information). - -Let's also suppose that we have a cleaned up graph like one after step -1) in the bisection algorithm above. This means that we can measure - the information we get in terms of number of commit we can remove - from the graph.. - -And let's take a commit X in the graph. - -If X is found to be "good", then we know that its ancestors are all -"good", so we want to say that: - -------------- -information_if_good(X) = number_of_ancestors(X) (TRUE) -------------- - -And this is true because at step 1) b) we remove the ancestors of the -"good" commits. - -If X is found to be "bad", then we know that its descendants are all -"bad", so we want to say that: - -------------- -information_if_bad(X) = number_of_descendants(X) (WRONG) -------------- - -But this is wrong because at step 1) a) we keep only the ancestors of -the bad commit. So we get more information when a commit is marked as -"bad", because we also know that the ancestors of the previous "bad" -commit that are not ancestors of the new "bad" commit are not the -first bad commit. We don't know if they are good or bad, but we know -that they are not the first bad commit because they are not ancestor -of the new "bad" commit. - -So when a commit is marked as "bad" we know we can remove all the -commits in the graph except those that are ancestors of the new "bad" -commit. This means that: - -------------- -information_if_bad(X) = N - number_of_ancestors(X) (TRUE) -------------- - -where N is the number of commits in the (cleaned up) graph. - -So in the end this means that to find the best bisection commits we -should maximize the function: - -------------- -f(X) = min(number_of_ancestors(X), N - number_of_ancestors(X)) -------------- - -And this is nice because at step 2) we compute number_of_ancestors(X) -and so at step 3) we compute f(X). - -Let's take the following graph as an example: - -------------- - G-H-I-J - / \ -A-B-C-D-E-F O - \ / - K-L-M-N -------------- - -If we compute the following non optimal function on it: - -------------- -g(X) = min(number_of_ancestors(X), number_of_descendants(X)) -------------- - -we get: - -------------- - 4 3 2 1 - G-H-I-J -1 2 3 4 5 6/ \0 -A-B-C-D-E-F O - \ / - K-L-M-N - 4 3 2 1 -------------- - -but with the algorithm used by git bisect we get: - -------------- - 7 7 6 5 - G-H-I-J -1 2 3 4 5 6/ \0 -A-B-C-D-E-F O - \ / - K-L-M-N - 7 7 6 5 -------------- - -So we chose G, H, K or L as the best bisection point, which is better -than F. Because if for example L is bad, then we will know not only -that L, M and N are bad but also that G, H, I and J are not the first -bad commit (since we suppose that there is only one first bad commit -and it must be an ancestor of L). - -So the current algorithm seems to be the best possible given what we -initially supposed. - -Skip algorithm -~~~~~~~~~~~~~~ - -When some commits have been skipped (using "git bisect skip"), then -the bisection algorithm is the same for step 1) to 3). But then we use -roughly the following steps: - -6) sort the commit by decreasing associated value - -7) if the first commit has not been skipped, we can return it and stop - here - -8) otherwise filter out all the skipped commits in the sorted list - -9) use a pseudo random number generator (PRNG) to generate a random - number between 0 and 1 - -10) multiply this random number with its square root to bias it toward - 0 - -11) multiply the result by the number of commits in the filtered list - to get an index into this list - -12) return the commit at the computed index - -Skip algorithm discussed -~~~~~~~~~~~~~~~~~~~~~~~~ - -After step 7) (in the skip algorithm), we could check if the second -commit has been skipped and return it if it is not the case. And in -fact that was the algorithm we used from when "git bisect skip" was -developed in Git version 1.5.4 (released on February 1st 2008) until -Git version 1.6.4 (released July 29th 2009). - -But Ingo Molnar and H. Peter Anvin (another well known linux kernel -developer) both complained that sometimes the best bisection points -all happened to be in an area where all the commits are -untestable. And in this case the user was asked to test many -untestable commits, which could be very inefficient. - -Indeed untestable commits are often untestable because a breakage was -introduced at one time, and that breakage was fixed only after many -other commits were introduced. - -This breakage is of course most of the time unrelated to the breakage -we are trying to locate in the commit graph. But it prevents us to -know if the interesting "bad behavior" is present or not. - -So it is a fact that commits near an untestable commit have a high -probability of being untestable themselves. And the best bisection -commits are often found together too (due to the bisection algorithm). - -This is why it is a bad idea to just chose the next best unskipped -bisection commit when the first one has been skipped. - -We found that most commits on the graph may give quite a lot of -information when they are tested. And the commits that will not on -average give a lot of information are the one near the good and bad -commits. - -So using a PRNG with a bias to favor commits away from the good and -bad commits looked like a good choice. - -One obvious improvement to this algorithm would be to look for a -commit that has an associated value near the one of the best bisection -commit, and that is on another branch, before using the PRNG. Because -if such a commit exists, then it is not very likely to be untestable -too, so it will probably give more information than a nearly randomly -chosen one. - -Checking merge bases -~~~~~~~~~~~~~~~~~~~~ - -There is another tweak in the bisection algorithm that has not been -described in the "bisection algorithm" above. - -We supposed in the previous examples that the "good" commits were -ancestors of the "bad" commit. But this is not a requirement of "git -bisect". - -Of course the "bad" commit cannot be an ancestor of a "good" commit, -because the ancestors of the good commits are supposed to be -"good". And all the "good" commits must be related to the bad commit. -They cannot be on a branch that has no link with the branch of the -"bad" commit. But it is possible for a good commit to be related to a -bad commit and yet not be neither one of its ancestor nor one of its -descendants. - -For example, there can be a "main" branch, and a "dev" branch that was -forked of the main branch at a commit named "D" like this: - -------------- -A-B-C-D-E-F-G <--main - \ - H-I-J <--dev -------------- - -The commit "D" is called a "merge base" for branch "main" and "dev" -because it's the best common ancestor for these branches for a merge. - -Now let's suppose that commit J is bad and commit G is good and that -we apply the bisection algorithm like it has been previously -described. - -As described in step 1) b) of the bisection algorithm, we remove all -the ancestors of the good commits because they are supposed to be good -too. - -So we would be left with only: - -------------- -H-I-J -------------- - -But what happens if the first bad commit is "B" and if it has been -fixed in the "main" branch by commit "F"? - -The result of such a bisection would be that we would find that H is -the first bad commit, when in fact it's B. So that would be wrong! - -And yes it can happen in practice that people working on one branch -are not aware that people working on another branch fixed a bug! It -could also happen that F fixed more than one bug or that it is a -revert of some big development effort that was not ready to be -released. - -In fact development teams often maintain both a development branch and -a maintenance branch, and it would be quite easy for them if "git -bisect" just worked when they want to bisect a regression on the -development branch that is not on the maintenance branch. They should -be able to start bisecting using: - -------------- -$ git bisect start dev main -------------- - -To enable that additional nice feature, when a bisection is started -and when some good commits are not ancestors of the bad commit, we -first compute the merge bases between the bad and the good commits and -we chose these merge bases as the first commits that will be checked -out and tested. - -If it happens that one merge base is bad, then the bisection process -is stopped with a message like: - -------------- -The merge base BBBBBB is bad. -This means the bug has been fixed between BBBBBB and [GGGGGG,...]. -------------- - -where BBBBBB is the sha1 hash of the bad merge base and [GGGGGG,...] -is a comma separated list of the sha1 of the good commits. - -If some of the merge bases are skipped, then the bisection process -continues, but the following message is printed for each skipped merge -base: - -------------- -Warning: the merge base between BBBBBB and [GGGGGG,...] must be skipped. -So we cannot be sure the first bad commit is between MMMMMM and BBBBBB. -We continue anyway. -------------- - -where BBBBBB is the sha1 hash of the bad commit, MMMMMM is the sha1 -hash of the merge base that is skipped and [GGGGGG,...] is a comma -separated list of the sha1 of the good commits. - -So if there is no bad merge base, the bisection process continues as -usual after this step. - -Best bisecting practices ------------------------- - -Using test suites and git bisect together -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -If you both have a test suite and use git bisect, then it becomes less -important to check that all tests pass after each commit. Though of -course it is probably a good idea to have some checks to avoid -breaking too many things because it could make bisecting other bugs -more difficult. - -You can focus your efforts to check at a few points (for example rc -and beta releases) that all the T test cases pass for all the N -configurations. And when some tests don't pass you can use "git -bisect" (or better "git bisect run"). So you should perform roughly: - -------------- -c * N * T + b * M * log2(M) tests -------------- - -where c is the number of rounds of test (so a small constant) and b is -the ratio of bug per commit (hopefully a small constant too). - -So of course it's much better as it's O(N * T) vs O(N * T * M) if -you would test everything after each commit. - -This means that test suites are good to prevent some bugs from being -committed and they are also quite good to tell you that you have some -bugs. But they are not so good to tell you where some bugs have been -introduced. To tell you that efficiently, git bisect is needed. - -The other nice thing with test suites, is that when you have one, you -already know how to test for bad behavior. So you can use this -knowledge to create a new test case for "git bisect" when it appears -that there is a regression. So it will be easier to bisect the bug and -fix it. And then you can add the test case you just created to your -test suite. - -So if you know how to create test cases and how to bisect, you will be -subject to a virtuous circle: - -more tests => easier to create tests => easier to bisect => more tests - -So test suites and "git bisect" are complementary tools that are very -powerful and efficient when used together. - -Bisecting build failures -~~~~~~~~~~~~~~~~~~~~~~~~ - -You can very easily automatically bisect broken builds using something -like: - -------------- -$ git bisect start BAD GOOD -$ git bisect run make -------------- - -Passing sh -c "some commands" to "git bisect run" -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -For example: - -------------- -$ git bisect run sh -c "make || exit 125; ./my_app | grep 'good output'" -------------- - -On the other hand if you do this often, then it can be worth having -scripts to avoid too much typing. - -Finding performance regressions -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Here is an example script that comes slightly modified from a real -world script used by Junio Hamano <<4>>. - -This script can be passed to "git bisect run" to find the commit that -introduced a performance regression: - -------------- -#!/bin/sh - -# Build errors are not what I am interested in. -make my_app || exit 255 - -# We are checking if it stops in a reasonable amount of time, so -# let it run in the background... - -./my_app >log 2>&1 & - -# ... and grab its process ID. -pid=$! - -# ... and then wait for sufficiently long. -sleep $NORMAL_TIME - -# ... and then see if the process is still there. -if kill -0 $pid -then - # It is still running -- that is bad. - kill $pid; sleep 1; kill $pid; - exit 1 -else - # It has already finished (the $pid process was no more), - # and we are happy. - exit 0 -fi -------------- - -Following general best practices -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -It is obviously a good idea not to have commits with changes that -knowingly break things, even if some other commits later fix the -breakage. - -It is also a good idea when using any VCS to have only one small -logical change in each commit. - -The smaller the changes in your commit, the most effective "git -bisect" will be. And you will probably need "git bisect" less in the -first place, as small changes are easier to review even if they are -only reviewed by the committer. - -Another good idea is to have good commit messages. They can be very -helpful to understand why some changes were made. - -These general best practices are very helpful if you bisect often. - -Avoiding bug prone merges -~~~~~~~~~~~~~~~~~~~~~~~~~ - -First merges by themselves can introduce some regressions even when -the merge needs no source code conflict resolution. This is because a -semantic change can happen in one branch while the other branch is not -aware of it. - -For example one branch can change the semantic of a function while the -other branch add more calls to the same function. - -This is made much worse if many files have to be fixed to resolve -conflicts. That's why such merges are called "evil merges". They can -make regressions very difficult to track down. It can even be -misleading to know the first bad commit if it happens to be such a -merge, because people might think that the bug comes from bad conflict -resolution when it comes from a semantic change in one branch. - -Anyway "git rebase" can be used to linearize history. This can be used -either to avoid merging in the first place. Or it can be used to -bisect on a linear history instead of the non linear one, as this -should give more information in case of a semantic change in one -branch. - -Merges can be also made simpler by using smaller branches or by using -many topic branches instead of only long version related branches. - -And testing can be done more often in special integration branches -like linux-next for the linux kernel. - -Adapting your work-flow -~~~~~~~~~~~~~~~~~~~~~~~ - -A special work-flow to process regressions can give great results. - -Here is an example of a work-flow used by Andreas Ericsson: - -* write, in the test suite, a test script that exposes the regression -* use "git bisect run" to find the commit that introduced it -* fix the bug that is often made obvious by the previous step -* commit both the fix and the test script (and if needed more tests) - -And here is what Andreas said about this work-flow <<5>>: - -_____________ -To give some hard figures, we used to have an average report-to-fix -cycle of 142.6 hours (according to our somewhat weird bug-tracker -which just measures wall-clock time). Since we moved to Git, we've -lowered that to 16.2 hours. Primarily because we can stay on top of -the bug fixing now, and because everyone's jockeying to get to fix -bugs (we're quite proud of how lazy we are to let Git find the bugs -for us). Each new release results in ~40% fewer bugs (almost certainly -due to how we now feel about writing tests). -_____________ - -Clearly this work-flow uses the virtuous circle between test suites -and "git bisect". In fact it makes it the standard procedure to deal -with regression. - -In other messages Andreas says that they also use the "best practices" -described above: small logical commits, topic branches, no evil -merge,... These practices all improve the bisectability of the commit -graph, by making it easier and more useful to bisect. - -So a good work-flow should be designed around the above points. That -is making bisecting easier, more useful and standard. - -Involving QA people and if possible end users -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -One nice about "git bisect" is that it is not only a developer -tool. It can effectively be used by QA people or even end users (if -they have access to the source code or if they can get access to all -the builds). - -There was a discussion at one point on the linux kernel mailing list -of whether it was ok to always ask end user to bisect, and very good -points were made to support the point of view that it is ok. - -For example David Miller wrote <<6>>: - -_____________ -What people don't get is that this is a situation where the "end node -principle" applies. When you have limited resources (here: developers) -you don't push the bulk of the burden upon them. Instead you push -things out to the resource you have a lot of, the end nodes (here: -users), so that the situation actually scales. -_____________ - -This means that it is often "cheaper" if QA people or end users can do -it. - -What is interesting too is that end users that are reporting bugs (or -QA people that reproduced a bug) have access to the environment where -the bug happens. So they can often more easily reproduce a -regression. And if they can bisect, then more information will be -extracted from the environment where the bug happens, which means that -it will be easier to understand and then fix the bug. - -For open source projects it can be a good way to get more useful -contributions from end users, and to introduce them to QA and -development activities. - -Using complex scripts -~~~~~~~~~~~~~~~~~~~~~ - -In some cases like for kernel development it can be worth developing -complex scripts to be able to fully automate bisecting. - -Here is what Ingo Molnar says about that <<7>>: - -_____________ -i have a fully automated bootup-hang bisection script. It is based on -"git-bisect run". I run the script, it builds and boots kernels fully -automatically, and when the bootup fails (the script notices that via -the serial log, which it continuously watches - or via a timeout, if -the system does not come up within 10 minutes it's a "bad" kernel), -the script raises my attention via a beep and i power cycle the test -box. (yeah, i should make use of a managed power outlet to 100% -automate it) -_____________ - -Combining test suites, git bisect and other systems together -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -We have seen that test suites and git bisect are very powerful when -used together. It can be even more powerful if you can combine them -with other systems. - -For example some test suites could be run automatically at night with -some unusual (or even random) configurations. And if a regression is -found by a test suite, then "git bisect" can be automatically -launched, and its result can be emailed to the author of the first bad -commit found by "git bisect", and perhaps other people too. And a new -entry in the bug tracking system could be automatically created too. - - -The future of bisecting ------------------------ - -"git replace" -~~~~~~~~~~~~~ - -We saw earlier that "git bisect skip" is now using a PRNG to try to -avoid areas in the commit graph where commits are untestable. The -problem is that sometimes the first bad commit will be in an -untestable area. - -To simplify the discussion we will suppose that the untestable area is -a simple string of commits and that it was created by a breakage -introduced by one commit (let's call it BBC for bisect breaking -commit) and later fixed by another one (let's call it BFC for bisect -fixing commit). - -For example: - -------------- -...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z-... -------------- - -where we know that Y is good and BFC is bad, and where BBC and X1 to -X6 are untestable. - -In this case if you are bisecting manually, what you can do is create -a special branch that starts just before the BBC. The first commit in -this branch should be the BBC with the BFC squashed into it. And the -other commits in the branch should be the commits between BBC and BFC -rebased on the first commit of the branch and then the commit after -BFC also rebased on. - -For example: - -------------- - (BBC+BFC)-X1'-X2'-X3'-X4'-X5'-X6'-Z' - / -...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z-... -------------- - -where commits quoted with ' have been rebased. - -You can easily create such a branch with Git using interactive rebase. - -For example using: - -------------- -$ git rebase -i Y Z -------------- - -and then moving BFC after BBC and squashing it. - -After that you can start bisecting as usual in the new branch and you -should eventually find the first bad commit. - -For example: - -------------- -$ git bisect start Z' Y -------------- - -If you are using "git bisect run", you can use the same manual fix up -as above, and then start another "git bisect run" in the special -branch. Or as the "git bisect" man page says, the script passed to -"git bisect run" can apply a patch before it compiles and test the -software <<8>>. The patch should turn a current untestable commits -into a testable one. So the testing will result in "good" or "bad" and -"git bisect" will be able to find the first bad commit. And the script -should not forget to remove the patch once the testing is done before -exiting from the script. - -(Note that instead of a patch you can use "git cherry-pick BFC" to -apply the fix, and in this case you should use "git reset --hard -HEAD^" to revert the cherry-pick after testing and before returning -from the script.) - -But the above ways to work around untestable areas are a little bit -clunky. Using special branches is nice because these branches can be -shared by developers like usual branches, but the risk is that people -will get many such branches. And it disrupts the normal "git bisect" -work-flow. So, if you want to use "git bisect run" completely -automatically, you have to add special code in your script to restart -bisection in the special branches. - -Anyway one can notice in the above special branch example that the Z' -and Z commits should point to the same source code state (the same -"tree" in git parlance). That's because Z' result from applying the -same changes as Z just in a slightly different order. - -So if we could just "replace" Z by Z' when we bisect, then we would -not need to add anything to a script. It would just work for anyone in -the project sharing the special branches and the replacements. - -With the example above that would give: - -------------- - (BBC+BFC)-X1'-X2'-X3'-X4'-X5'-X6'-Z'-... - / -...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z -------------- - -That's why the "git replace" command was created. Technically it -stores replacements "refs" in the "refs/replace/" hierarchy. These -"refs" are like branches (that are stored in "refs/heads/") or tags -(that are stored in "refs/tags"), and that means that they can -automatically be shared like branches or tags among developers. - -"git replace" is a very powerful mechanism. It can be used to fix -commits in already released history, for example to change the commit -message or the author. And it can also be used instead of git "grafts" -to link a repository with another old repository. - -In fact it's this last feature that "sold" it to the Git community, so -it is now in the "master" branch of Git's Git repository and it should -be released in Git 1.6.5 in October or November 2009. - -One problem with "git replace" is that currently it stores all the -replacements refs in "refs/replace/", but it would be perhaps better -if the replacement refs that are useful only for bisecting would be in -"refs/replace/bisect/". This way the replacement refs could be used -only for bisecting, while other refs directly in "refs/replace/" would -be used nearly all the time. - -Bisecting sporadic bugs -~~~~~~~~~~~~~~~~~~~~~~~ - -Another possible improvement to "git bisect" would be to optionally -add some redundancy to the tests performed so that it would be more -reliable when tracking sporadic bugs. - -This has been requested by some kernel developers because some bugs -called sporadic bugs do not appear in all the kernel builds because -they are very dependent on the compiler output. - -The idea is that every 3 test for example, "git bisect" could ask the -user to test a commit that has already been found to be "good" or -"bad" (because one of its descendants or one of its ancestors has been -found to be "good" or "bad" respectively). If it happens that a commit -has been previously incorrectly classified then the bisection can be -aborted early, hopefully before too many mistakes have been made. Then -the user will have to look at what happened and then restart the -bisection using a fixed bisect log. - -There is already a project called BBChop created by Ealdwulf Wuffinga -on Github that does something like that using Bayesian Search Theory -<<9>>: - -_____________ -BBChop is like 'git bisect' (or equivalent), but works when your bug -is intermittent. That is, it works in the presence of false negatives -(when a version happens to work this time even though it contains the -bug). It assumes that there are no false positives (in principle, the -same approach would work, but adding it may be non-trivial). -_____________ - -But BBChop is independent of any VCS and it would be easier for Git -users to have something integrated in Git. - -Conclusion ----------- - -We have seen that regressions are an important problem, and that "git -bisect" has nice features that complement very well practices and -other tools, especially test suites, that are generally used to fight -regressions. But it might be needed to change some work-flows and -(bad) habits to get the most out of it. - -Some improvements to the algorithms inside "git bisect" are possible -and some new features could help in some cases, but overall "git -bisect" works already very well, is used a lot, and is already very -useful. To back up that last claim, let's give the final word to Ingo -Molnar when he was asked by the author how much time does he think -"git bisect" saves him when he uses it: - -_____________ -a _lot_. - -About ten years ago did i do my first 'bisection' of a Linux patch -queue. That was prior the Git (and even prior the BitKeeper) days. I -literally days spent sorting out patches, creating what in essence -were standalone commits that i guessed to be related to that bug. - -It was a tool of absolute last resort. I'd rather spend days looking -at printk output than do a manual 'patch bisection'. - -With Git bisect it's a breeze: in the best case i can get a ~15 step -kernel bisection done in 20-30 minutes, in an automated way. Even with -manual help or when bisecting multiple, overlapping bugs, it's rarely -more than an hour. - -In fact it's invaluable because there are bugs i would never even -_try_ to debug if it wasn't for git bisect. In the past there were bug -patterns that were immediately hopeless for me to debug - at best i -could send the crash/bug signature to lkml and hope that someone else -can think of something. - -And even if a bisection fails today it tells us something valuable -about the bug: that it's non-deterministic - timing or kernel image -layout dependent. - -So git bisect is unconditional goodness - and feel free to quote that -;-) -_____________ - -Acknowledgments ---------------- - -Many thanks to Junio Hamano for his help in reviewing this paper, for -reviewing the patches I sent to the Git mailing list, for discussing -some ideas and helping me improve them, for improving "git bisect" a -lot and for his awesome work in maintaining and developing Git. - -Many thanks to Ingo Molnar for giving me very useful information that -appears in this paper, for commenting on this paper, for his -suggestions to improve "git bisect" and for evangelizing "git bisect" -on the linux kernel mailing lists. - -Many thanks to Linus Torvalds for inventing, developing and -evangelizing "git bisect", Git and Linux. - -Many thanks to the many other great people who helped one way or -another when I worked on Git, especially to Andreas Ericsson, Johannes -Schindelin, H. Peter Anvin, Daniel Barkalow, Bill Lear, John Hawley, -Shawn O. Pierce, Jeff King, Sam Vilain, Jon Seymour. - -Many thanks to the Linux-Kongress program committee for choosing the -author to given a talk and for publishing this paper. - -References ----------- - -- [[[1]]] https://www.nist.gov/sites/default/files/documents/director/planning/report02-3.pdf['The Economic Impacts of Inadequate Infratructure for Software Testing'. Nist Planning Report 02-3], see Executive Summary and Chapter 8. -- [[[2]]] http://www.oracle.com/technetwork/java/codeconvtoc-136057.html['Code Conventions for the Java Programming Language'. Sun Microsystems.] -- [[[3]]] https://en.wikipedia.org/wiki/Software_maintenance['Software maintenance'. Wikipedia.] -- [[[4]]] https://lore.kernel.org/git/7vps5xsbwp.fsf_-_@assigned-by-dhcp.cox.net/[Junio C Hamano. 'Automated bisect success story'.] -- [[[5]]] https://lwn.net/Articles/317154/[Christian Couder. 'Fully automated bisecting with "git bisect run"'. LWN.net.] -- [[[6]]] https://lwn.net/Articles/277872/[Jonathan Corbet. 'Bisection divides users and developers'. LWN.net.] -- [[[7]]] https://lore.kernel.org/lkml/20071207113734.GA14598@elte.hu/[Ingo Molnar. 'Re: BUG 2.6.23-rc3 can't see sd partitions on Alpha'. Linux-kernel mailing list.] -- [[[8]]] https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html[Junio C Hamano and the git-list. 'git-bisect(1) Manual Page'. Linux Kernel Archives.] -- [[[9]]] https://github.com/Ealdwulf/bbchop[Ealdwulf. 'bbchop'. GitHub.] |