diff options
Diffstat (limited to 'third_party/git/Documentation/git-bisect-lk2009.txt')
| -rw-r--r-- | third_party/git/Documentation/git-bisect-lk2009.txt | 22 |
1 files changed, 11 insertions, 11 deletions
diff --git a/third_party/git/Documentation/git-bisect-lk2009.txt b/third_party/git/Documentation/git-bisect-lk2009.txt index e99925184d..f3d9566c89 100644 --- a/third_party/git/Documentation/git-bisect-lk2009.txt +++ b/third_party/git/Documentation/git-bisect-lk2009.txt @@ -158,7 +158,7 @@ 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 -combinational explosion. +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 @@ -473,7 +473,7 @@ Z-Z ------------- 2) starting from the "good" ends of the graph, associate to each -commit the number of ancestors it has plus one + 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: @@ -514,7 +514,7 @@ D---E ------------- 4) the best bisection point is the commit with the highest associated -number + number So in the above example the best bisection point is commit C. @@ -580,8 +580,8 @@ 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.. + 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. @@ -689,18 +689,18 @@ 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 + 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 + number between 0 and 1 10) multiply this random number with its square root to bias it toward -0 + 0 11) multiply the result by the number of commits in the filtered list -to get an index into this list + to get an index into this list 12) return the commit at the computed index @@ -1350,9 +1350,9 @@ 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://public-inbox.org/git/7vps5xsbwp.fsf_-_@assigned-by-dhcp.cox.net/[Junio C Hamano. 'Automated bisect success story'.] +- [[[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]]] http://marc.info/?l=linux-kernel&m=119702753411680&w=2[Ingo Molnar. 'Re: BUG 2.6.23-rc3 can't see sd partitions on Alpha'. Linux-kernel mailing list.] +- [[[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.] |