|
|
<!DOCTYPE html> |
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en"> |
|
|
<head> |
|
|
<meta charset="UTF-8"/> |
|
|
<meta http-equiv="X-UA-Compatible" content="IE=edge"/> |
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0"/> |
|
|
<meta name="generator" content="Asciidoctor 2.0.17"/> |
|
|
<meta name="author" content="Christian Couder"/> |
|
|
<title>Fighting regressions with git bisect</title> |
|
|
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Open+Sans:300,300italic,400,400italic,600,600italic%7CNoto+Serif:400,400italic,700,700italic%7CDroid+Sans+Mono:400,700"/> |
|
|
<style> |
|
|
|
|
|
|
|
|
|
|
|
html{font-family:sans-serif;-webkit-text-size-adjust:100%} |
|
|
a{background:none} |
|
|
a:focus{outline:thin dotted} |
|
|
a:active,a:hover{outline:0} |
|
|
h1{font-size:2em;margin:.67em 0} |
|
|
b,strong{font-weight:bold} |
|
|
abbr{font-size:.9em} |
|
|
abbr[title]{cursor:help;border-bottom:1px dotted #dddddf;text-decoration:none} |
|
|
dfn{font-style:italic} |
|
|
hr{height:0} |
|
|
mark{background:#ff0;color:#000} |
|
|
code,kbd,pre,samp{font-family:monospace;font-size:1em} |
|
|
pre{white-space:pre-wrap} |
|
|
q{quotes:"\201C" "\201D" "\2018" "\2019"} |
|
|
small{font-size:80%} |
|
|
sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline} |
|
|
sup{top:-.5em} |
|
|
sub{bottom:-.25em} |
|
|
img{border:0} |
|
|
svg:not(:root){overflow:hidden} |
|
|
figure{margin:0} |
|
|
audio,video{display:inline-block} |
|
|
audio:not([controls]){display:none;height:0} |
|
|
fieldset{border:1px solid silver;margin:0 2px;padding:.35em .625em .75em} |
|
|
legend{border:0;padding:0} |
|
|
button,input,select,textarea{font-family:inherit;font-size:100%;margin:0} |
|
|
button,input{line-height:normal} |
|
|
button,select{text-transform:none} |
|
|
button,html input[type=button],input[type=reset],input[type=submit]{-webkit-appearance:button;cursor:pointer} |
|
|
button[disabled],html input[disabled]{cursor:default} |
|
|
input[type=checkbox],input[type=radio]{padding:0} |
|
|
button::-moz-focus-inner,input::-moz-focus-inner{border:0;padding:0} |
|
|
textarea{overflow:auto;vertical-align:top} |
|
|
table{border-collapse:collapse;border-spacing:0} |
|
|
*,::before,::after{box-sizing:border-box} |
|
|
html,body{font-size:100%} |
|
|
body{background:#fff;color:rgba(0,0,0,.8);padding:0;margin:0;font-family:"Noto Serif","DejaVu Serif",serif;line-height:1;position:relative;cursor:auto;-moz-tab-size:4;-o-tab-size:4;tab-size:4;word-wrap:anywhere;-moz-osx-font-smoothing:grayscale;-webkit-font-smoothing:antialiased} |
|
|
a:hover{cursor:pointer} |
|
|
img,object,embed{max-width:100%;height:auto} |
|
|
object,embed{height:100%} |
|
|
img{-ms-interpolation-mode:bicubic} |
|
|
.left{float:left!important} |
|
|
.right{float:right!important} |
|
|
.text-left{text-align:left!important} |
|
|
.text-right{text-align:right!important} |
|
|
.text-center{text-align:center!important} |
|
|
.text-justify{text-align:justify!important} |
|
|
.hide{display:none} |
|
|
img,object,svg{display:inline-block;vertical-align:middle} |
|
|
textarea{height:auto;min-height:50px} |
|
|
select{width:100%} |
|
|
.subheader,.admonitionblock td.content>.title,.audioblock>.title,.exampleblock>.title,.imageblock>.title,.listingblock>.title,.literalblock>.title,.stemblock>.title,.openblock>.title,.paragraph>.title,.quoteblock>.title,table.tableblock>.title,.verseblock>.title,.videoblock>.title,.dlist>.title,.olist>.title,.ulist>.title,.qlist>.title,.hdlist>.title{line-height:1.45;color:#7a2518;font-weight:400;margin-top:0;margin-bottom:.25em} |
|
|
div,dl,dt,dd,ul,ol,li,h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6,pre,form,p,blockquote,th,td{margin:0;padding:0} |
|
|
a{color:#2156a5;text-decoration:underline;line-height:inherit} |
|
|
a:hover,a:focus{color:#1d4b8f} |
|
|
a img{border:0} |
|
|
p{line-height:1.6;margin-bottom:1.25em;text-rendering:optimizeLegibility} |
|
|
p aside{font-size:.875em;line-height:1.35;font-style:italic} |
|
|
h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{font-family:"Open Sans","DejaVu Sans",sans-serif;font-weight:300;font-style:normal;color:#ba3925;text-rendering:optimizeLegibility;margin-top:1em;margin-bottom:.5em;line-height:1.0125em} |
|
|
h1 small,h2 small,h3 small,#toctitle small,.sidebarblock>.content>.title small,h4 small,h5 small,h6 small{font-size:60%;color:#e99b8f;line-height:0} |
|
|
h1{font-size:2.125em} |
|
|
h2{font-size:1.6875em} |
|
|
h3,#toctitle,.sidebarblock>.content>.title{font-size:1.375em} |
|
|
h4,h5{font-size:1.125em} |
|
|
h6{font-size:1em} |
|
|
hr{border:solid #dddddf;border-width:1px 0 0;clear:both;margin:1.25em 0 1.1875em} |
|
|
em,i{font-style:italic;line-height:inherit} |
|
|
strong,b{font-weight:bold;line-height:inherit} |
|
|
small{font-size:60%;line-height:inherit} |
|
|
code{font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;font-weight:400;color:rgba(0,0,0,.9)} |
|
|
ul,ol,dl{line-height:1.6;margin-bottom:1.25em;list-style-position:outside;font-family:inherit} |
|
|
ul,ol{margin-left:1.5em} |
|
|
ul li ul,ul li ol{margin-left:1.25em;margin-bottom:0} |
|
|
ul.square li ul,ul.circle li ul,ul.disc li ul{list-style:inherit} |
|
|
ul.square{list-style-type:square} |
|
|
ul.circle{list-style-type:circle} |
|
|
ul.disc{list-style-type:disc} |
|
|
ol li ul,ol li ol{margin-left:1.25em;margin-bottom:0} |
|
|
dl dt{margin-bottom:.3125em;font-weight:bold} |
|
|
dl dd{margin-bottom:1.25em} |
|
|
blockquote{margin:0 0 1.25em;padding:.5625em 1.25em 0 1.1875em;border-left:1px solid #ddd} |
|
|
blockquote,blockquote p{line-height:1.6;color:rgba(0,0,0,.85)} |
|
|
@media screen and (min-width:768px){h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{line-height:1.2} |
|
|
h1{font-size:2.75em} |
|
|
h2{font-size:2.3125em} |
|
|
h3,#toctitle,.sidebarblock>.content>.title{font-size:1.6875em} |
|
|
h4{font-size:1.4375em}} |
|
|
table{background:#fff;margin-bottom:1.25em;border:1px solid #dedede;word-wrap:normal} |
|
|
table thead,table tfoot{background:#f7f8f7} |
|
|
table thead tr th,table thead tr td,table tfoot tr th,table tfoot tr td{padding:.5em .625em .625em;font-size:inherit;color:rgba(0,0,0,.8);text-align:left} |
|
|
table tr th,table tr td{padding:.5625em .625em;font-size:inherit;color:rgba(0,0,0,.8)} |
|
|
table tr.even,table tr.alt{background:#f8f8f7} |
|
|
table thead tr th,table tfoot tr th,table tbody tr td,table tr td,table tfoot tr td{line-height:1.6} |
|
|
h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{line-height:1.2;word-spacing:-.05em} |
|
|
h1 strong,h2 strong,h3 strong,#toctitle strong,.sidebarblock>.content>.title strong,h4 strong,h5 strong,h6 strong{font-weight:400} |
|
|
.center{margin-left:auto;margin-right:auto} |
|
|
.stretch{width:100%} |
|
|
.clearfix::before,.clearfix::after,.float-group::before,.float-group::after{content:" ";display:table} |
|
|
.clearfix::after,.float-group::after{clear:both} |
|
|
:not(pre).nobreak{word-wrap:normal} |
|
|
:not(pre).nowrap{white-space:nowrap} |
|
|
:not(pre).pre-wrap{white-space:pre-wrap} |
|
|
:not(pre):not([class^=L])>code{font-size:.9375em;font-style:normal!important;letter-spacing:0;padding:.1em .5ex;word-spacing:-.15em;background:#f7f7f8;border-radius:4px;line-height:1.45;text-rendering:optimizeSpeed} |
|
|
pre{color:rgba(0,0,0,.9);font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;line-height:1.45;text-rendering:optimizeSpeed} |
|
|
pre code,pre pre{color:inherit;font-size:inherit;line-height:inherit} |
|
|
pre>code{display:block} |
|
|
pre.nowrap,pre.nowrap pre{white-space:pre;word-wrap:normal} |
|
|
em em{font-style:normal} |
|
|
strong strong{font-weight:400} |
|
|
.keyseq{color:rgba(51,51,51,.8)} |
|
|
kbd{font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;display:inline-block;color:rgba(0,0,0,.8);font-size:.65em;line-height:1.45;background:#f7f7f7;border:1px solid #ccc;border-radius:3px;box-shadow:0 1px 0 rgba(0,0,0,.2),inset 0 0 0 .1em #fff;margin:0 .15em;padding:.2em .5em;vertical-align:middle;position:relative;top:-.1em;white-space:nowrap} |
|
|
.keyseq kbd:first-child{margin-left:0} |
|
|
.keyseq kbd:last-child{margin-right:0} |
|
|
.menuseq,.menuref{color:#000} |
|
|
.menuseq b:not(.caret),.menuref{font-weight:inherit} |
|
|
.menuseq{word-spacing:-.02em} |
|
|
.menuseq b.caret{font-size:1.25em;line-height:.8} |
|
|
.menuseq i.caret{font-weight:bold;text-align:center;width:.45em} |
|
|
b.button::before,b.button::after{position:relative;top:-1px;font-weight:400} |
|
|
b.button::before{content:"[";padding:0 3px 0 2px} |
|
|
b.button::after{content:"]";padding:0 2px 0 3px} |
|
|
p a>code:hover{color:rgba(0,0,0,.9)} |
|
|
#header,#content,#footnotes,#footer{width:100%;margin:0 auto;max-width:62.5em;*zoom:1;position:relative;padding-left:.9375em;padding-right:.9375em} |
|
|
#header::before,#header::after,#content::before,#content::after,#footnotes::before,#footnotes::after,#footer::before,#footer::after{content:" ";display:table} |
|
|
#header::after,#content::after,#footnotes::after,#footer::after{clear:both} |
|
|
#content{margin-top:1.25em} |
|
|
#content::before{content:none} |
|
|
#header>h1:first-child{color:rgba(0,0,0,.85);margin-top:2.25rem;margin-bottom:0} |
|
|
#header>h1:first-child+#toc{margin-top:8px;border-top:1px solid #dddddf} |
|
|
#header>h1:only-child,body.toc2 #header>h1:nth-last-child(2){border-bottom:1px solid #dddddf;padding-bottom:8px} |
|
|
#header .details{border-bottom:1px solid #dddddf;line-height:1.45;padding-top:.25em;padding-bottom:.25em;padding-left:.25em;color:rgba(0,0,0,.6);display:flex;flex-flow:row wrap} |
|
|
#header .details span:first-child{margin-left:-.125em} |
|
|
#header .details span.email a{color:rgba(0,0,0,.85)} |
|
|
#header .details br{display:none} |
|
|
#header .details br+span::before{content:"\00a0\2013\00a0"} |
|
|
#header .details br+span.author::before{content:"\00a0\22c5\00a0";color:rgba(0,0,0,.85)} |
|
|
#header .details br+span#revremark::before{content:"\00a0|\00a0"} |
|
|
#header #revnumber{text-transform:capitalize} |
|
|
#header #revnumber::after{content:"\00a0"} |
|
|
#content>h1:first-child:not([class]){color:rgba(0,0,0,.85);border-bottom:1px solid #dddddf;padding-bottom:8px;margin-top:0;padding-top:1rem;margin-bottom:1.25rem} |
|
|
#toc{border-bottom:1px solid #e7e7e9;padding-bottom:.5em} |
|
|
#toc>ul{margin-left:.125em} |
|
|
#toc ul.sectlevel0>li>a{font-style:italic} |
|
|
#toc ul.sectlevel0 ul.sectlevel1{margin:.5em 0} |
|
|
#toc ul{font-family:"Open Sans","DejaVu Sans",sans-serif;list-style-type:none} |
|
|
#toc li{line-height:1.3334;margin-top:.3334em} |
|
|
#toc a{text-decoration:none} |
|
|
#toc a:active{text-decoration:underline} |
|
|
#toctitle{color:#7a2518;font-size:1.2em} |
|
|
@media screen and (min-width:768px){#toctitle{font-size:1.375em} |
|
|
body.toc2{padding-left:15em;padding-right:0} |
|
|
#toc.toc2{margin-top:0!important;background:#f8f8f7;position:fixed;width:15em;left:0;top:0;border-right:1px solid #e7e7e9;border-top-width:0!important;border-bottom-width:0!important;z-index:1000;padding:1.25em 1em;height:100%;overflow:auto} |
|
|
#toc.toc2 #toctitle{margin-top:0;margin-bottom:.8rem;font-size:1.2em} |
|
|
#toc.toc2>ul{font-size:.9em;margin-bottom:0} |
|
|
#toc.toc2 ul ul{margin-left:0;padding-left:1em} |
|
|
#toc.toc2 ul.sectlevel0 ul.sectlevel1{padding-left:0;margin-top:.5em;margin-bottom:.5em} |
|
|
body.toc2.toc-right{padding-left:0;padding-right:15em} |
|
|
body.toc2.toc-right #toc.toc2{border-right-width:0;border-left:1px solid #e7e7e9;left:auto;right:0}} |
|
|
@media screen and (min-width:1280px){body.toc2{padding-left:20em;padding-right:0} |
|
|
#toc.toc2{width:20em} |
|
|
#toc.toc2 #toctitle{font-size:1.375em} |
|
|
#toc.toc2>ul{font-size:.95em} |
|
|
#toc.toc2 ul ul{padding-left:1.25em} |
|
|
body.toc2.toc-right{padding-left:0;padding-right:20em}} |
|
|
#content #toc{border:1px solid #e0e0dc;margin-bottom:1.25em;padding:1.25em;background:#f8f8f7;border-radius:4px} |
|
|
#content #toc>:first-child{margin-top:0} |
|
|
#content #toc>:last-child{margin-bottom:0} |
|
|
#footer{max-width:none;background:rgba(0,0,0,.8);padding:1.25em} |
|
|
#footer-text{color:hsla(0,0%,100%,.8);line-height:1.44} |
|
|
#content{margin-bottom:.625em} |
|
|
.sect1{padding-bottom:.625em} |
|
|
@media screen and (min-width:768px){#content{margin-bottom:1.25em} |
|
|
.sect1{padding-bottom:1.25em}} |
|
|
.sect1:last-child{padding-bottom:0} |
|
|
.sect1+.sect1{border-top:1px solid #e7e7e9} |
|
|
#content h1>a.anchor,h2>a.anchor,h3>a.anchor,#toctitle>a.anchor,.sidebarblock>.content>.title>a.anchor,h4>a.anchor,h5>a.anchor,h6>a.anchor{position:absolute;z-index:1001;width:1.5ex;margin-left:-1.5ex;display:block;text-decoration:none!important;visibility:hidden;text-align:center;font-weight:400} |
|
|
#content h1>a.anchor::before,h2>a.anchor::before,h3>a.anchor::before,#toctitle>a.anchor::before,.sidebarblock>.content>.title>a.anchor::before,h4>a.anchor::before,h5>a.anchor::before,h6>a.anchor::before{content:"\00A7";font-size:.85em;display:block;padding-top:.1em} |
|
|
#content h1:hover>a.anchor,#content h1>a.anchor:hover,h2:hover>a.anchor,h2>a.anchor:hover,h3:hover>a.anchor,#toctitle:hover>a.anchor,.sidebarblock>.content>.title:hover>a.anchor,h3>a.anchor:hover,#toctitle>a.anchor:hover,.sidebarblock>.content>.title>a.anchor:hover,h4:hover>a.anchor,h4>a.anchor:hover,h5:hover>a.anchor,h5>a.anchor:hover,h6:hover>a.anchor,h6>a.anchor:hover{visibility:visible} |
|
|
#content h1>a.link,h2>a.link,h3>a.link,#toctitle>a.link,.sidebarblock>.content>.title>a.link,h4>a.link,h5>a.link,h6>a.link{color:#ba3925;text-decoration:none} |
|
|
#content h1>a.link:hover,h2>a.link:hover,h3>a.link:hover,#toctitle>a.link:hover,.sidebarblock>.content>.title>a.link:hover,h4>a.link:hover,h5>a.link:hover,h6>a.link:hover{color:#a53221} |
|
|
details,.audioblock,.imageblock,.literalblock,.listingblock,.stemblock,.videoblock{margin-bottom:1.25em} |
|
|
details{margin-left:1.25rem} |
|
|
details>summary{cursor:pointer;display:block;position:relative;line-height:1.6;margin-bottom:.625rem;outline:none;-webkit-tap-highlight-color:transparent} |
|
|
details>summary::-webkit-details-marker{display:none} |
|
|
details>summary::before{content:"";border:solid transparent;border-left:solid;border-width:.3em 0 .3em .5em;position:absolute;top:.5em;left:-1.25rem;transform:translateX(15%)} |
|
|
details[open]>summary::before{border:solid transparent;border-top:solid;border-width:.5em .3em 0;transform:translateY(15%)} |
|
|
details>summary::after{content:"";width:1.25rem;height:1em;position:absolute;top:.3em;left:-1.25rem} |
|
|
.admonitionblock td.content>.title,.audioblock>.title,.exampleblock>.title,.imageblock>.title,.listingblock>.title,.literalblock>.title,.stemblock>.title,.openblock>.title,.paragraph>.title,.quoteblock>.title,table.tableblock>.title,.verseblock>.title,.videoblock>.title,.dlist>.title,.olist>.title,.ulist>.title,.qlist>.title,.hdlist>.title{text-rendering:optimizeLegibility;text-align:left;font-family:"Noto Serif","DejaVu Serif",serif;font-size:1rem;font-style:italic} |
|
|
table.tableblock.fit-content>caption.title{white-space:nowrap;width:0} |
|
|
.paragraph.lead>p,#preamble>.sectionbody>[class=paragraph]:first-of-type p{font-size:1.21875em;line-height:1.6;color:rgba(0,0,0,.85)} |
|
|
.admonitionblock>table{border-collapse:separate;border:0;background:none;width:100%} |
|
|
.admonitionblock>table td.icon{text-align:center;width:80px} |
|
|
.admonitionblock>table td.icon img{max-width:none} |
|
|
.admonitionblock>table td.icon .title{font-weight:bold;font-family:"Open Sans","DejaVu Sans",sans-serif;text-transform:uppercase} |
|
|
.admonitionblock>table td.content{padding-left:1.125em;padding-right:1.25em;border-left:1px solid #dddddf;color:rgba(0,0,0,.6);word-wrap:anywhere} |
|
|
.admonitionblock>table td.content>:last-child>:last-child{margin-bottom:0} |
|
|
.exampleblock>.content{border:1px solid #e6e6e6;margin-bottom:1.25em;padding:1.25em;background:#fff;border-radius:4px} |
|
|
.exampleblock>.content>:first-child{margin-top:0} |
|
|
.exampleblock>.content>:last-child{margin-bottom:0} |
|
|
.sidebarblock{border:1px solid #dbdbd6;margin-bottom:1.25em;padding:1.25em;background:#f3f3f2;border-radius:4px} |
|
|
.sidebarblock>:first-child{margin-top:0} |
|
|
.sidebarblock>:last-child{margin-bottom:0} |
|
|
.sidebarblock>.content>.title{color:#7a2518;margin-top:0;text-align:center} |
|
|
.exampleblock>.content>:last-child>:last-child,.exampleblock>.content .olist>ol>li:last-child>:last-child,.exampleblock>.content .ulist>ul>li:last-child>:last-child,.exampleblock>.content .qlist>ol>li:last-child>:last-child,.sidebarblock>.content>:last-child>:last-child,.sidebarblock>.content .olist>ol>li:last-child>:last-child,.sidebarblock>.content .ulist>ul>li:last-child>:last-child,.sidebarblock>.content .qlist>ol>li:last-child>:last-child{margin-bottom:0} |
|
|
.literalblock pre,.listingblock>.content>pre{border-radius:4px;overflow-x:auto;padding:1em;font-size:.8125em} |
|
|
@media screen and (min-width:768px){.literalblock pre,.listingblock>.content>pre{font-size:.90625em}} |
|
|
@media screen and (min-width:1280px){.literalblock pre,.listingblock>.content>pre{font-size:1em}} |
|
|
.literalblock pre,.listingblock>.content>pre:not(.highlight),.listingblock>.content>pre[class=highlight],.listingblock>.content>pre[class^="highlight "]{background:#f7f7f8} |
|
|
.literalblock.output pre{color:#f7f7f8;background:rgba(0,0,0,.9)} |
|
|
.listingblock>.content{position:relative} |
|
|
.listingblock code[data-lang]::before{display:none;content:attr(data-lang);position:absolute;font-size:.75em;top:.425rem;right:.5rem;line-height:1;text-transform:uppercase;color:inherit;opacity:.5} |
|
|
.listingblock:hover code[data-lang]::before{display:block} |
|
|
.listingblock.terminal pre .command::before{content:attr(data-prompt);padding-right:.5em;color:inherit;opacity:.5} |
|
|
.listingblock.terminal pre .command:not([data-prompt])::before{content:"$"} |
|
|
.listingblock pre.highlightjs{padding:0} |
|
|
.listingblock pre.highlightjs>code{padding:1em;border-radius:4px} |
|
|
.listingblock pre.prettyprint{border-width:0} |
|
|
.prettyprint{background:#f7f7f8} |
|
|
pre.prettyprint .linenums{line-height:1.45;margin-left:2em} |
|
|
pre.prettyprint li{background:none;list-style-type:inherit;padding-left:0} |
|
|
pre.prettyprint li code[data-lang]::before{opacity:1} |
|
|
pre.prettyprint li:not(:first-child) code[data-lang]::before{display:none} |
|
|
table.linenotable{border-collapse:separate;border:0;margin-bottom:0;background:none} |
|
|
table.linenotable td[class]{color:inherit;vertical-align:top;padding:0;line-height:inherit;white-space:normal} |
|
|
table.linenotable td.code{padding-left:.75em} |
|
|
table.linenotable td.linenos,pre.pygments .linenos{border-right:1px solid;opacity:.35;padding-right:.5em;-webkit-user-select:none;-moz-user-select:none;-ms-user-select:none;user-select:none} |
|
|
pre.pygments span.linenos{display:inline-block;margin-right:.75em} |
|
|
.quoteblock{margin:0 1em 1.25em 1.5em;display:table} |
|
|
.quoteblock:not(.excerpt)>.title{margin-left:-1.5em;margin-bottom:.75em} |
|
|
.quoteblock blockquote,.quoteblock p{color:rgba(0,0,0,.85);font-size:1.15rem;line-height:1.75;word-spacing:.1em;letter-spacing:0;font-style:italic;text-align:justify} |
|
|
.quoteblock blockquote{margin:0;padding:0;border:0} |
|
|
.quoteblock blockquote::before{content:"\201c";float:left;font-size:2.75em;font-weight:bold;line-height:.6em;margin-left:-.6em;color:#7a2518;text-shadow:0 1px 2px rgba(0,0,0,.1)} |
|
|
.quoteblock blockquote>.paragraph:last-child p{margin-bottom:0} |
|
|
.quoteblock .attribution{margin-top:.75em;margin-right:.5ex;text-align:right} |
|
|
.verseblock{margin:0 1em 1.25em} |
|
|
.verseblock pre{font-family:"Open Sans","DejaVu Sans",sans-serif;font-size:1.15rem;color:rgba(0,0,0,.85);font-weight:300;text-rendering:optimizeLegibility} |
|
|
.verseblock pre strong{font-weight:400} |
|
|
.verseblock .attribution{margin-top:1.25rem;margin-left:.5ex} |
|
|
.quoteblock .attribution,.verseblock .attribution{font-size:.9375em;line-height:1.45;font-style:italic} |
|
|
.quoteblock .attribution br,.verseblock .attribution br{display:none} |
|
|
.quoteblock .attribution cite,.verseblock .attribution cite{display:block;letter-spacing:-.025em;color:rgba(0,0,0,.6)} |
|
|
.quoteblock.abstract blockquote::before,.quoteblock.excerpt blockquote::before,.quoteblock .quoteblock blockquote::before{display:none} |
|
|
.quoteblock.abstract blockquote,.quoteblock.abstract p,.quoteblock.excerpt blockquote,.quoteblock.excerpt p,.quoteblock .quoteblock blockquote,.quoteblock .quoteblock p{line-height:1.6;word-spacing:0} |
|
|
.quoteblock.abstract{margin:0 1em 1.25em;display:block} |
|
|
.quoteblock.abstract>.title{margin:0 0 .375em;font-size:1.15em;text-align:center} |
|
|
.quoteblock.excerpt>blockquote,.quoteblock .quoteblock{padding:0 0 .25em 1em;border-left:.25em solid #dddddf} |
|
|
.quoteblock.excerpt,.quoteblock .quoteblock{margin-left:0} |
|
|
.quoteblock.excerpt blockquote,.quoteblock.excerpt p,.quoteblock .quoteblock blockquote,.quoteblock .quoteblock p{color:inherit;font-size:1.0625rem} |
|
|
.quoteblock.excerpt .attribution,.quoteblock .quoteblock .attribution{color:inherit;font-size:.85rem;text-align:left;margin-right:0} |
|
|
p.tableblock:last-child{margin-bottom:0} |
|
|
td.tableblock>.content{margin-bottom:1.25em;word-wrap:anywhere} |
|
|
td.tableblock>.content>:last-child{margin-bottom:-1.25em} |
|
|
table.tableblock,th.tableblock,td.tableblock{border:0 solid #dedede} |
|
|
table.grid-all>*>tr>*{border-width:1px} |
|
|
table.grid-cols>*>tr>*{border-width:0 1px} |
|
|
table.grid-rows>*>tr>*{border-width:1px 0} |
|
|
table.frame-all{border-width:1px} |
|
|
table.frame-ends{border-width:1px 0} |
|
|
table.frame-sides{border-width:0 1px} |
|
|
table.frame-none>colgroup+*>:first-child>*,table.frame-sides>colgroup+*>:first-child>*{border-top-width:0} |
|
|
table.frame-none>:last-child>:last-child>*,table.frame-sides>:last-child>:last-child>*{border-bottom-width:0} |
|
|
table.frame-none>*>tr>:first-child,table.frame-ends>*>tr>:first-child{border-left-width:0} |
|
|
table.frame-none>*>tr>:last-child,table.frame-ends>*>tr>:last-child{border-right-width:0} |
|
|
table.stripes-all>*>tr,table.stripes-odd>*>tr:nth-of-type(odd),table.stripes-even>*>tr:nth-of-type(even),table.stripes-hover>*>tr:hover{background:#f8f8f7} |
|
|
th.halign-left,td.halign-left{text-align:left} |
|
|
th.halign-right,td.halign-right{text-align:right} |
|
|
th.halign-center,td.halign-center{text-align:center} |
|
|
th.valign-top,td.valign-top{vertical-align:top} |
|
|
th.valign-bottom,td.valign-bottom{vertical-align:bottom} |
|
|
th.valign-middle,td.valign-middle{vertical-align:middle} |
|
|
table thead th,table tfoot th{font-weight:bold} |
|
|
tbody tr th{background:#f7f8f7} |
|
|
tbody tr th,tbody tr th p,tfoot tr th,tfoot tr th p{color:rgba(0,0,0,.8);font-weight:bold} |
|
|
p.tableblock>code:only-child{background:none;padding:0} |
|
|
p.tableblock{font-size:1em} |
|
|
ol{margin-left:1.75em} |
|
|
ul li ol{margin-left:1.5em} |
|
|
dl dd{margin-left:1.125em} |
|
|
dl dd:last-child,dl dd:last-child>:last-child{margin-bottom:0} |
|
|
li p,ul dd,ol dd,.olist .olist,.ulist .ulist,.ulist .olist,.olist .ulist{margin-bottom:.625em} |
|
|
ul.checklist,ul.none,ol.none,ul.no-bullet,ol.no-bullet,ol.unnumbered,ul.unstyled,ol.unstyled{list-style-type:none} |
|
|
ul.no-bullet,ol.no-bullet,ol.unnumbered{margin-left:.625em} |
|
|
ul.unstyled,ol.unstyled{margin-left:0} |
|
|
li>p:empty:only-child::before{content:"";display:inline-block} |
|
|
ul.checklist>li>p:first-child{margin-left:-1em} |
|
|
ul.checklist>li>p:first-child>.fa-square-o:first-child,ul.checklist>li>p:first-child>.fa-check-square-o:first-child{width:1.25em;font-size:.8em;position:relative;bottom:.125em} |
|
|
ul.checklist>li>p:first-child>input[type=checkbox]:first-child{margin-right:.25em} |
|
|
ul.inline{display:flex;flex-flow:row wrap;list-style:none;margin:0 0 .625em -1.25em} |
|
|
ul.inline>li{margin-left:1.25em} |
|
|
.unstyled dl dt{font-weight:400;font-style:normal} |
|
|
ol.arabic{list-style-type:decimal} |
|
|
ol.decimal{list-style-type:decimal-leading-zero} |
|
|
ol.loweralpha{list-style-type:lower-alpha} |
|
|
ol.upperalpha{list-style-type:upper-alpha} |
|
|
ol.lowerroman{list-style-type:lower-roman} |
|
|
ol.upperroman{list-style-type:upper-roman} |
|
|
ol.lowergreek{list-style-type:lower-greek} |
|
|
.hdlist>table,.colist>table{border:0;background:none} |
|
|
.hdlist>table>tbody>tr,.colist>table>tbody>tr{background:none} |
|
|
td.hdlist1,td.hdlist2{vertical-align:top;padding:0 .625em} |
|
|
td.hdlist1{font-weight:bold;padding-bottom:1.25em} |
|
|
td.hdlist2{word-wrap:anywhere} |
|
|
.literalblock+.colist,.listingblock+.colist{margin-top:-.5em} |
|
|
.colist td:not([class]):first-child{padding:.4em .75em 0;line-height:1;vertical-align:top} |
|
|
.colist td:not([class]):first-child img{max-width:none} |
|
|
.colist td:not([class]):last-child{padding:.25em 0} |
|
|
.thumb,.th{line-height:0;display:inline-block;border:4px solid #fff;box-shadow:0 0 0 1px #ddd} |
|
|
.imageblock.left{margin:.25em .625em 1.25em 0} |
|
|
.imageblock.right{margin:.25em 0 1.25em .625em} |
|
|
.imageblock>.title{margin-bottom:0} |
|
|
.imageblock.thumb,.imageblock.th{border-width:6px} |
|
|
.imageblock.thumb>.title,.imageblock.th>.title{padding:0 .125em} |
|
|
.image.left,.image.right{margin-top:.25em;margin-bottom:.25em;display:inline-block;line-height:0} |
|
|
.image.left{margin-right:.625em} |
|
|
.image.right{margin-left:.625em} |
|
|
a.image{text-decoration:none;display:inline-block} |
|
|
a.image object{pointer-events:none} |
|
|
sup.footnote,sup.footnoteref{font-size:.875em;position:static;vertical-align:super} |
|
|
sup.footnote a,sup.footnoteref a{text-decoration:none} |
|
|
sup.footnote a:active,sup.footnoteref a:active{text-decoration:underline} |
|
|
#footnotes{padding-top:.75em;padding-bottom:.75em;margin-bottom:.625em} |
|
|
#footnotes hr{width:20%;min-width:6.25em;margin:-.25em 0 .75em;border-width:1px 0 0} |
|
|
#footnotes .footnote{padding:0 .375em 0 .225em;line-height:1.3334;font-size:.875em;margin-left:1.2em;margin-bottom:.2em} |
|
|
#footnotes .footnote a:first-of-type{font-weight:bold;text-decoration:none;margin-left:-1.05em} |
|
|
#footnotes .footnote:last-of-type{margin-bottom:0} |
|
|
#content #footnotes{margin-top:-.625em;margin-bottom:0;padding:.75em 0} |
|
|
div.unbreakable{page-break-inside:avoid} |
|
|
.big{font-size:larger} |
|
|
.small{font-size:smaller} |
|
|
.underline{text-decoration:underline} |
|
|
.overline{text-decoration:overline} |
|
|
.line-through{text-decoration:line-through} |
|
|
.aqua{color:#00bfbf} |
|
|
.aqua-background{background:#00fafa} |
|
|
.black{color:#000} |
|
|
.black-background{background:#000} |
|
|
.blue{color:#0000bf} |
|
|
.blue-background{background:#0000fa} |
|
|
.fuchsia{color:#bf00bf} |
|
|
.fuchsia-background{background:#fa00fa} |
|
|
.gray{color:#606060} |
|
|
.gray-background{background:#7d7d7d} |
|
|
.green{color:#006000} |
|
|
.green-background{background:#007d00} |
|
|
.lime{color:#00bf00} |
|
|
.lime-background{background:#00fa00} |
|
|
.maroon{color:#600000} |
|
|
.maroon-background{background:#7d0000} |
|
|
.navy{color:#000060} |
|
|
.navy-background{background:#00007d} |
|
|
.olive{color:#606000} |
|
|
.olive-background{background:#7d7d00} |
|
|
.purple{color:#600060} |
|
|
.purple-background{background:#7d007d} |
|
|
.red{color:#bf0000} |
|
|
.red-background{background:#fa0000} |
|
|
.silver{color:#909090} |
|
|
.silver-background{background:#bcbcbc} |
|
|
.teal{color:#006060} |
|
|
.teal-background{background:#007d7d} |
|
|
.white{color:#bfbfbf} |
|
|
.white-background{background:#fafafa} |
|
|
.yellow{color:#bfbf00} |
|
|
.yellow-background{background:#fafa00} |
|
|
span.icon>.fa{cursor:default} |
|
|
a span.icon>.fa{cursor:inherit} |
|
|
.admonitionblock td.icon [class^="fa icon-"]{font-size:2.5em;text-shadow:1px 1px 2px rgba(0,0,0,.5);cursor:default} |
|
|
.admonitionblock td.icon .icon-note::before{content:"\f05a";color:#19407c} |
|
|
.admonitionblock td.icon .icon-tip::before{content:"\f0eb";text-shadow:1px 1px 2px rgba(155,155,0,.8);color:#111} |
|
|
.admonitionblock td.icon .icon-warning::before{content:"\f071";color:#bf6900} |
|
|
.admonitionblock td.icon .icon-caution::before{content:"\f06d";color:#bf3400} |
|
|
.admonitionblock td.icon .icon-important::before{content:"\f06a";color:#bf0000} |
|
|
.conum[data-value]{display:inline-block;color:#fff!important;background:rgba(0,0,0,.8);border-radius:50%;text-align:center;font-size:.75em;width:1.67em;height:1.67em;line-height:1.67em;font-family:"Open Sans","DejaVu Sans",sans-serif;font-style:normal;font-weight:bold} |
|
|
.conum[data-value] *{color:#fff!important} |
|
|
.conum[data-value]+b{display:none} |
|
|
.conum[data-value]::after{content:attr(data-value)} |
|
|
pre .conum[data-value]{position:relative;top:-.125em} |
|
|
b.conum *{color:inherit!important} |
|
|
.conum:not([data-value]):empty{display:none} |
|
|
dt,th.tableblock,td.content,div.footnote{text-rendering:optimizeLegibility} |
|
|
h1,h2,p,td.content,span.alt,summary{letter-spacing:-.01em} |
|
|
p strong,td.content strong,div.footnote strong{letter-spacing:-.005em} |
|
|
p,blockquote,dt,td.content,span.alt,summary{font-size:1.0625rem} |
|
|
p{margin-bottom:1.25rem} |
|
|
.sidebarblock p,.sidebarblock dt,.sidebarblock td.content,p.tableblock{font-size:1em} |
|
|
.exampleblock>.content{background:#fffef7;border-color:#e0e0dc;box-shadow:0 1px 4px #e0e0dc} |
|
|
.print-only{display:none!important} |
|
|
@page{margin:1.25cm .75cm} |
|
|
@media print{*{box-shadow:none!important;text-shadow:none!important} |
|
|
html{font-size:80%} |
|
|
a{color:inherit!important;text-decoration:underline!important} |
|
|
a.bare,a[href^="#"],a[href^="mailto:"]{text-decoration:none!important} |
|
|
a[href^="http:"]:not(.bare)::after,a[href^="https:"]:not(.bare)::after{content:"(" attr(href) ")";display:inline-block;font-size:.875em;padding-left:.25em} |
|
|
abbr[title]{border-bottom:1px dotted} |
|
|
abbr[title]::after{content:" (" attr(title) ")"} |
|
|
pre,blockquote,tr,img,object,svg{page-break-inside:avoid} |
|
|
thead{display:table-header-group} |
|
|
svg{max-width:100%} |
|
|
p,blockquote,dt,td.content{font-size:1em;orphans:3;widows:3} |
|
|
h2,h3,#toctitle,.sidebarblock>.content>.title{page-break-after:avoid} |
|
|
#header,#content,#footnotes,#footer{max-width:none} |
|
|
#toc,.sidebarblock,.exampleblock>.content{background:none!important} |
|
|
#toc{border-bottom:1px solid #dddddf!important;padding-bottom:0!important} |
|
|
body.book #header{text-align:center} |
|
|
body.book #header>h1:first-child{border:0!important;margin:2.5em 0 1em} |
|
|
body.book #header .details{border:0!important;display:block;padding:0!important} |
|
|
body.book #header .details span:first-child{margin-left:0!important} |
|
|
body.book #header .details br{display:block} |
|
|
body.book #header .details br+span::before{content:none!important} |
|
|
body.book #toc{border:0!important;text-align:left!important;padding:0!important;margin:0!important} |
|
|
body.book #toc,body.book #preamble,body.book h1.sect0,body.book .sect1>h2{page-break-before:always} |
|
|
.listingblock code[data-lang]::before{display:block} |
|
|
#footer{padding:0 .9375em} |
|
|
.hide-on-print{display:none!important} |
|
|
.print-only{display:block!important} |
|
|
.hide-for-print{display:none!important} |
|
|
.show-for-print{display:inherit!important}} |
|
|
@media amzn-kf8,print{#header>h1:first-child{margin-top:1.25rem} |
|
|
.sect1{padding:0!important} |
|
|
.sect1+.sect1{border:0} |
|
|
#footer{background:none} |
|
|
#footer-text{color:rgba(0,0,0,.6);font-size:.9em}} |
|
|
@media amzn-kf8{#header,#content,#footnotes,#footer{padding:0}} |
|
|
</style> |
|
|
</head> |
|
|
<body class="article"> |
|
|
<div id="header"> |
|
|
<h1>Fighting regressions with git bisect</h1> |
|
|
<div class="details"> |
|
|
<span id="author" class="author">Christian Couder</span><br/> |
|
|
<span id="email" class="email"><a href="mailto:[email protected]">[email protected]</a></span><br/> |
|
|
</div> |
|
|
</div> |
|
|
<div id="content"> |
|
|
<div class="sect1"> |
|
|
<h2 id="_abstract">Abstract</h2> |
|
|
<div class="sectionbody"> |
|
|
<div class="paragraph"> |
|
|
<p>"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.</p> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect1"> |
|
|
<h2 id="_introduction_to_git_bisect">Introduction to "git bisect"</h2> |
|
|
<div class="sectionbody"> |
|
|
<div class="paragraph"> |
|
|
<p>Git is a Distributed Version Control system (DVCS) created by Linus |
|
|
Torvalds and maintained by Junio Hamano.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect1"> |
|
|
<h2 id="_fighting_regressions_overview">Fighting regressions overview</h2> |
|
|
<div class="sectionbody"> |
|
|
<div class="sect2"> |
|
|
<h3 id="_regressions_a_big_problem">Regressions: a big problem</h3> |
|
|
<div class="paragraph"> |
|
|
<p>Regressions are a big problem in the software industry. But it’s |
|
|
difficult to put some real numbers behind that claim.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>There are some numbers about bugs in general, like a NIST study in |
|
|
2002 <a href="#1">[1]</a> that said:</p> |
|
|
</div> |
|
|
<div class="quoteblock"> |
|
|
<blockquote> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
</blockquote> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>And then:</p> |
|
|
</div> |
|
|
<div class="quoteblock"> |
|
|
<blockquote> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
</blockquote> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>Eventually the conclusion started with:</p> |
|
|
</div> |
|
|
<div class="quoteblock"> |
|
|
<blockquote> |
|
|
<div class="paragraph"> |
|
|
<p>The path to higher software quality is significantly improved software |
|
|
testing.</p> |
|
|
</div> |
|
|
</blockquote> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>There are other estimates saying that 80% of the cost related to |
|
|
software is about maintenance <a href="#2">[2]</a>.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>Though, according to Wikipedia <a href="#3">[3]</a>:</p> |
|
|
</div> |
|
|
<div class="quoteblock"> |
|
|
<blockquote> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
</blockquote> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>And then this is what Ingo Molnar (a well known Linux kernel |
|
|
developer) says about his use of git bisect:</p> |
|
|
</div> |
|
|
<div class="quoteblock"> |
|
|
<blockquote> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
</blockquote> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_other_tools_to_fight_regressions">Other tools to fight regressions</h3> |
|
|
<div class="paragraph"> |
|
|
<p>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".</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>N * M * T tests</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>where N, M and T are all growing with the size your software.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>So very soon it will not be possible to completely test everything.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect1"> |
|
|
<h2 id="_git_bisect_overview">"git bisect" overview</h2> |
|
|
<div class="sectionbody"> |
|
|
<div class="sect2"> |
|
|
<h3 id="_starting_a_bisection">Starting a bisection</h3> |
|
|
<div class="paragraph"> |
|
|
<p>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:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>$ git bisect start [BAD [GOOD...]]</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>or they can be set using:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>$ git bisect bad [COMMIT]</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>and:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>$ git bisect good [COMMIT...]</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>where BAD, GOOD and COMMIT are all names that can be resolved to a |
|
|
commit.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>Then "git bisect" will checkout a commit of its choosing and ask the |
|
|
user to test it, like this:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>$ 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</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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>").</p> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_driving_a_bisection_manually">Driving a bisection manually</h3> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>$ git bisect bad |
|
|
Bisecting: 5480 revisions left to test after this (roughly 13 steps) |
|
|
[66c0b394f08fd89236515c1c84485ea712a157be] KVM: kill file->f_count abuse in kvm</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>And after a few more steps like that, "git bisect" will eventually |
|
|
find a first bad commit:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>$ git bisect bad |
|
|
2ddcca36c8bcfa251724fe342c8327451988be0d is the first bad commit |
|
|
commit 2ddcca36c8bcfa251724fe342c8327451988be0d |
|
|
Author: Linus Torvalds <[email protected]> |
|
|
Date: Sat May 3 11:59:44 2008 -0700 |
|
|
|
|
|
Linux 2.6.26-rc1 |
|
|
|
|
|
:100644 100644 5cf82581... 4492984e... M Makefile</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>$ git show HEAD |
|
|
commit 2ddcca36c8bcfa251724fe342c8327451988be0d |
|
|
Author: Linus Torvalds <[email protected]> |
|
|
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*</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>And when we are finished we can use "git bisect reset" to go back to |
|
|
the branch we were in before we started bisecting:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>$ git bisect reset |
|
|
Checking out files: 100% (21549/21549), done. |
|
|
Previous HEAD position was 2ddcca3... Linux 2.6.26-rc1 |
|
|
Switched to branch 'master'</pre> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_driving_a_bisection_automatically">Driving a bisection automatically</h3> |
|
|
<div class="paragraph"> |
|
|
<p>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:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>$ 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 <[email protected]> |
|
|
Date: Sat May 3 11:59:44 2008 -0700 |
|
|
|
|
|
Linux 2.6.26-rc1 |
|
|
|
|
|
:100644 100644 5cf82581... 4492984e... M Makefile |
|
|
bisect run success</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>In this example, we passed "grep <em>^SUBLEVEL = 25</em> 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".</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>It can also be useful in scripts passed to "git bisect run" to "exit |
|
|
255" if some very abnormal situation is detected.</p> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_avoiding_untestable_commits">Avoiding untestable commits</h3> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.)</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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 <code>DISPLAY</code> environment variable is not set) to help you find a |
|
|
better bisection point.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>So if you used "git bisect skip" (or the run script exited with |
|
|
special code 125) you could get a result like this:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>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!</pre> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_saving_a_log_and_replaying_it">Saving a log and replaying it</h3> |
|
|
<div class="paragraph"> |
|
|
<p>If you want to show other people your bisection process, you can get a |
|
|
log using for example:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>$ git bisect log > bisect_log.txt</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>And it is possible to replay it using:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>$ git bisect replay bisect_log.txt</pre> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect1"> |
|
|
<h2 id="_git_bisect_details">"git bisect" details</h2> |
|
|
<div class="sectionbody"> |
|
|
<div class="sect2"> |
|
|
<h3 id="_bisection_algorithm">Bisection algorithm</h3> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>So the algorithm used by "git bisect" to find the best bisection |
|
|
commit when there are no skipped commits is the following:</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>1) keep only the commits that:</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>a) are ancestor of the "bad" commit (including the "bad" commit itself), |
|
|
b) are not ancestor of a "good" commit (excluding the "good" commits).</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>This means that we get rid of the uninteresting commits in the DAG.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>For example if we start with a graph like this:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>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 -></pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>W-W-W |
|
|
\ |
|
|
W-W-B |
|
|
/ |
|
|
W---W</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>Note for Git users, that it is equivalent as keeping only the commit |
|
|
given by:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>git rev-list BAD --not GOOD1 GOOD2...</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>G-W-W-W-B |
|
|
/ |
|
|
Z-Z</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>2) starting from the "good" ends of the graph, associate to each |
|
|
commit the number of ancestors it has plus one</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>For example with the following graph where H is the "bad" commit and A |
|
|
and D are some parents of some "good" commits:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>A-B-C |
|
|
\ |
|
|
F-G-H |
|
|
/ |
|
|
D---E</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>this will give:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>1 2 3 |
|
|
A-B-C |
|
|
\6 7 8 |
|
|
F-G-H |
|
|
1 2/ |
|
|
D---E</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>3) associate to each commit: min(X, N - X)</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>where X is the value associated to the commit in step 2) and N is the |
|
|
total number of commits in the graph.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>In the above example we have N = 8, so this will give:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>1 2 3 |
|
|
A-B-C |
|
|
\2 1 0 |
|
|
F-G-H |
|
|
1 2/ |
|
|
D---E</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>4) the best bisection point is the commit with the highest associated |
|
|
number</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>So in the above example the best bisection point is commit C.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>5) note that some shortcuts are implemented to speed up the algorithm</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_bisection_algorithm_debugging">Bisection algorithm debugging</h3> |
|
|
<div class="paragraph"> |
|
|
<p>For any commit graph, you can see the number associated with each |
|
|
commit using "git rev-list --bisect-all".</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>For example, for the above graph, a command like:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>$ git rev-list --bisect-all BAD --not GOOD1 GOOD2</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>would output something like:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>e15b73ad3db9b48d7d1ade32f8cd23a751fe0ace (dist=3) |
|
|
15722f2fa328eaba97022898a305ffc8172db6b1 (dist=2) |
|
|
78e86cf3e850bd755bb71831f42e200626fbd1e0 (dist=2) |
|
|
a1939d9a142de972094af4dde9a544e577ddef0e (dist=2) |
|
|
070eab2303024706f2924822bfec8b9847e4ac1b (dist=1) |
|
|
a3864d4f32a3bf5ed177ddef598490a08760b70d (dist=1) |
|
|
a41baa717dd74f1180abf55e9341bc7a0bb9d556 (dist=1) |
|
|
9e622a6dad403b71c40979743bb9d5be17b16bd6 (dist=0)</pre> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_bisection_algorithm_discussed">Bisection algorithm discussed</h3> |
|
|
<div class="paragraph"> |
|
|
<p>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".</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>This means that the best bisection commits are the commits where the |
|
|
following function is maximum:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>f(X) = min(information_if_good(X), information_if_bad(X))</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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).</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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..</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>And let’s take a commit X in the graph.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>If X is found to be "good", then we know that its ancestors are all |
|
|
"good", so we want to say that:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>information_if_good(X) = number_of_ancestors(X) (TRUE)</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>And this is true because at step 1) b) we remove the ancestors of the |
|
|
"good" commits.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>If X is found to be "bad", then we know that its descendants are all |
|
|
"bad", so we want to say that:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>information_if_bad(X) = number_of_descendants(X) (WRONG)</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>information_if_bad(X) = N - number_of_ancestors(X) (TRUE)</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>where N is the number of commits in the (cleaned up) graph.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>So in the end this means that to find the best bisection commits we |
|
|
should maximize the function:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>f(X) = min(number_of_ancestors(X), N - number_of_ancestors(X))</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>And this is nice because at step 2) we compute number_of_ancestors(X) |
|
|
and so at step 3) we compute f(X).</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>Let’s take the following graph as an example:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre> G-H-I-J |
|
|
/ \ |
|
|
A-B-C-D-E-F O |
|
|
\ / |
|
|
K-L-M-N</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>If we compute the following non optimal function on it:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>g(X) = min(number_of_ancestors(X), number_of_descendants(X))</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>we get:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre> 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</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>but with the algorithm used by git bisect we get:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre> 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</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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).</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>So the current algorithm seems to be the best possible given what we |
|
|
initially supposed.</p> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_skip_algorithm">Skip algorithm</h3> |
|
|
<div class="paragraph"> |
|
|
<p>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:</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>6) sort the commit by decreasing associated value</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>7) if the first commit has not been skipped, we can return it and stop |
|
|
here</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>8) otherwise filter out all the skipped commits in the sorted list</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>9) use a pseudo random number generator (PRNG) to generate a random |
|
|
number between 0 and 1</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>10) multiply this random number with its square root to bias it toward |
|
|
0</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>11) multiply the result by the number of commits in the filtered list |
|
|
to get an index into this list</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>12) return the commit at the computed index</p> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_skip_algorithm_discussed">Skip algorithm discussed</h3> |
|
|
<div class="paragraph"> |
|
|
<p>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).</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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).</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>This is why it is a bad idea to just chose the next best unskipped |
|
|
bisection commit when the first one has been skipped.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>So using a PRNG with a bias to favor commits away from the good and |
|
|
bad commits looked like a good choice.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_checking_merge_bases">Checking merge bases</h3> |
|
|
<div class="paragraph"> |
|
|
<p>There is another tweak in the bisection algorithm that has not been |
|
|
described in the "bisection algorithm" above.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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".</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>A-B-C-D-E-F-G <--main |
|
|
\ |
|
|
H-I-J <--dev</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>So we would be left with only:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>H-I-J</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>But what happens if the first bad commit is "B" and if it has been |
|
|
fixed in the "main" branch by commit "F"?</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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!</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>$ git bisect start dev main</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>If it happens that one merge base is bad, then the bisection process |
|
|
is stopped with a message like:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>The merge base BBBBBB is bad. |
|
|
This means the bug has been fixed between BBBBBB and [GGGGGG,...].</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>If some of the merge bases are skipped, then the bisection process |
|
|
continues, but the following message is printed for each skipped merge |
|
|
base:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>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.</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>So if there is no bad merge base, the bisection process continues as |
|
|
usual after this step.</p> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect1"> |
|
|
<h2 id="_best_bisecting_practices">Best bisecting practices</h2> |
|
|
<div class="sectionbody"> |
|
|
<div class="sect2"> |
|
|
<h3 id="_using_test_suites_and_git_bisect_together">Using test suites and git bisect together</h3> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>c * N * T + b * M * log2(M) tests</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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).</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>So if you know how to create test cases and how to bisect, you will be |
|
|
subject to a virtuous circle:</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>more tests ⇒ easier to create tests ⇒ easier to bisect ⇒ more tests</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>So test suites and "git bisect" are complementary tools that are very |
|
|
powerful and efficient when used together.</p> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_bisecting_build_failures">Bisecting build failures</h3> |
|
|
<div class="paragraph"> |
|
|
<p>You can very easily automatically bisect broken builds using something |
|
|
like:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>$ git bisect start BAD GOOD |
|
|
$ git bisect run make</pre> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_passing_sh_c_some_commands_to_git_bisect_run">Passing sh -c "some commands" to "git bisect run"</h3> |
|
|
<div class="paragraph"> |
|
|
<p>For example:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>$ git bisect run sh -c "make || exit 125; ./my_app | grep 'good output'"</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>On the other hand if you do this often, then it can be worth having |
|
|
scripts to avoid too much typing.</p> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_finding_performance_regressions">Finding performance regressions</h3> |
|
|
<div class="paragraph"> |
|
|
<p>Here is an example script that comes slightly modified from a real |
|
|
world script used by Junio Hamano <a href="#4">[4]</a>.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>This script can be passed to "git bisect run" to find the commit that |
|
|
introduced a performance regression:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>#!/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</pre> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_following_general_best_practices">Following general best practices</h3> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>It is also a good idea when using any VCS to have only one small |
|
|
logical change in each commit.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>Another good idea is to have good commit messages. They can be very |
|
|
helpful to understand why some changes were made.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>These general best practices are very helpful if you bisect often.</p> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_avoiding_bug_prone_merges">Avoiding bug prone merges</h3> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>For example one branch can change the semantic of a function while the |
|
|
other branch add more calls to the same function.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>Merges can be also made simpler by using smaller branches or by using |
|
|
many topic branches instead of only long version related branches.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>And testing can be done more often in special integration branches |
|
|
like linux-next for the linux kernel.</p> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_adapting_your_work_flow">Adapting your work-flow</h3> |
|
|
<div class="paragraph"> |
|
|
<p>A special work-flow to process regressions can give great results.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>Here is an example of a work-flow used by Andreas Ericsson:</p> |
|
|
</div> |
|
|
<div class="ulist"> |
|
|
<ul> |
|
|
<li> |
|
|
<p>write, in the test suite, a test script that exposes the regression</p> |
|
|
</li> |
|
|
<li> |
|
|
<p>use "git bisect run" to find the commit that introduced it</p> |
|
|
</li> |
|
|
<li> |
|
|
<p>fix the bug that is often made obvious by the previous step</p> |
|
|
</li> |
|
|
<li> |
|
|
<p>commit both the fix and the test script (and if needed more tests)</p> |
|
|
</li> |
|
|
</ul> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>And here is what Andreas said about this work-flow <a href="#5">[5]</a>:</p> |
|
|
</div> |
|
|
<div class="quoteblock"> |
|
|
<blockquote> |
|
|
<div class="paragraph"> |
|
|
<p>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).</p> |
|
|
</div> |
|
|
</blockquote> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>So a good work-flow should be designed around the above points. That |
|
|
is making bisecting easier, more useful and standard.</p> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_involving_qa_people_and_if_possible_end_users">Involving QA people and if possible end users</h3> |
|
|
<div class="paragraph"> |
|
|
<p>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).</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>For example David Miller wrote <a href="#6">[6]</a>:</p> |
|
|
</div> |
|
|
<div class="quoteblock"> |
|
|
<blockquote> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
</blockquote> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>This means that it is often "cheaper" if QA people or end users can do |
|
|
it.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_using_complex_scripts">Using complex scripts</h3> |
|
|
<div class="paragraph"> |
|
|
<p>In some cases like for kernel development it can be worth developing |
|
|
complex scripts to be able to fully automate bisecting.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>Here is what Ingo Molnar says about that <a href="#7">[7]</a>:</p> |
|
|
</div> |
|
|
<div class="quoteblock"> |
|
|
<blockquote> |
|
|
<div class="paragraph"> |
|
|
<p>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)</p> |
|
|
</div> |
|
|
</blockquote> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_combining_test_suites_git_bisect_and_other_systems_together">Combining test suites, git bisect and other systems together</h3> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect1"> |
|
|
<h2 id="_the_future_of_bisecting">The future of bisecting</h2> |
|
|
<div class="sectionbody"> |
|
|
<div class="sect2"> |
|
|
<h3 id="_git_replace">"git replace"</h3> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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).</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>For example:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z-...</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>where we know that Y is good and BFC is bad, and where BBC and X1 to |
|
|
X6 are untestable.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>For example:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre> (BBC+BFC)-X1'-X2'-X3'-X4'-X5'-X6'-Z' |
|
|
/ |
|
|
...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z-...</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>where commits quoted with ' have been rebased.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>You can easily create such a branch with Git using interactive rebase.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>For example using:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>$ git rebase -i Y Z</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>and then moving BFC after BBC and squashing it.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>After that you can start bisecting as usual in the new branch and you |
|
|
should eventually find the first bad commit.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>For example:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre>$ git bisect start Z' Y</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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 <a href="#8">[8]</a>. 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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>(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.)</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>With the example above that would give:</p> |
|
|
</div> |
|
|
<div class="listingblock"> |
|
|
<div class="content"> |
|
|
<pre> (BBC+BFC)-X1'-X2'-X3'-X4'-X5'-X6'-Z'-... |
|
|
/ |
|
|
...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z</pre> |
|
|
</div> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>"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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect2"> |
|
|
<h3 id="_bisecting_sporadic_bugs">Bisecting sporadic bugs</h3> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>There is already a project called BBChop created by Ealdwulf Wuffinga |
|
|
on Github that does something like that using Bayesian Search Theory |
|
|
<a href="#9">[9]</a>:</p> |
|
|
</div> |
|
|
<div class="quoteblock"> |
|
|
<blockquote> |
|
|
<div class="paragraph"> |
|
|
<p>BBChop is like <em>git bisect</em> (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).</p> |
|
|
</div> |
|
|
</blockquote> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>But BBChop is independent of any VCS and it would be easier for Git |
|
|
users to have something integrated in Git.</p> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect1"> |
|
|
<h2 id="_conclusion">Conclusion</h2> |
|
|
<div class="sectionbody"> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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:</p> |
|
|
</div> |
|
|
<div class="quoteblock"> |
|
|
<blockquote> |
|
|
<div class="paragraph"> |
|
|
<p>a <em>lot</em>.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>About ten years ago did i do my first <em>bisection</em> 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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>It was a tool of absolute last resort. I’d rather spend days looking |
|
|
at printk output than do a manual <em>patch bisection</em>.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>In fact it’s invaluable because there are bugs i would never even |
|
|
<em>try</em> 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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>So git bisect is unconditional goodness - and feel free to quote that |
|
|
;-)</p> |
|
|
</div> |
|
|
</blockquote> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect1"> |
|
|
<h2 id="_acknowledgments">Acknowledgments</h2> |
|
|
<div class="sectionbody"> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>Many thanks to Linus Torvalds for inventing, developing and |
|
|
evangelizing "git bisect", Git and Linux.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>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.</p> |
|
|
</div> |
|
|
<div class="paragraph"> |
|
|
<p>Many thanks to the Linux-Kongress program committee for choosing the |
|
|
author to given a talk and for publishing this paper.</p> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
<div class="sect1"> |
|
|
<h2 id="_references">References</h2> |
|
|
<div class="sectionbody"> |
|
|
<div class="ulist"> |
|
|
<ul> |
|
|
<li> |
|
|
<p>[[[1]]] <a href="https://web.archive.org/web/20091206032101/http://www.nist.gov/public_affairs/releases/n02-10.htm"><em>Software Errors Cost U.S. Economy $59.5 Billion Annually</em>. Nist News Release.</a> See also <a href="https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf"><em>The Economic Impacts of Inadequate Infratructure for Software Testing</em>. Nist Planning Report 02-3</a>, Executive Summary and Chapter 8.</p> |
|
|
</li> |
|
|
<li> |
|
|
<p>[[[2]]] <a href="https://www.oracle.com/java/technologies/javase/codeconventions-introduction.html"><em>Code Conventions for the Java Programming Language: 1. Introduction</em>. Sun Microsystems.</a></p> |
|
|
</li> |
|
|
<li> |
|
|
<p>[[[3]]] <a href="https://en.wikipedia.org/wiki/Software_maintenance"><em>Software maintenance</em>. Wikipedia.</a></p> |
|
|
</li> |
|
|
<li> |
|
|
<p>[[[4]]] <a href="https://lore.kernel.org/git/[email protected]/">Junio C Hamano. <em>Automated bisect success story</em>.</a></p> |
|
|
</li> |
|
|
<li> |
|
|
<p>[[[5]]] <a href="https://lwn.net/Articles/317154/">Christian Couder. <em>Fully automated bisecting with "git bisect run"</em>. LWN.net.</a></p> |
|
|
</li> |
|
|
<li> |
|
|
<p>[[[6]]] <a href="https://lwn.net/Articles/277872/">Jonathan Corbet. <em>Bisection divides users and developers</em>. LWN.net.</a></p> |
|
|
</li> |
|
|
<li> |
|
|
<p>[[[7]]] <a href="https://lore.kernel.org/lkml/[email protected]/">Ingo Molnar. <em>Re: BUG 2.6.23-rc3 can’t see sd partitions on Alpha</em>. Linux-kernel mailing list.</a></p> |
|
|
</li> |
|
|
<li> |
|
|
<p>[[[8]]] <a href="https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html">Junio C Hamano and the git-list. <em>git-bisect(1) Manual Page</em>. Linux Kernel Archives.</a></p> |
|
|
</li> |
|
|
<li> |
|
|
<p>[[[9]]] <a href="https://github.com/Ealdwulf/bbchop">Ealdwulf. <em>bbchop</em>. GitHub.</a></p> |
|
|
</li> |
|
|
</ul> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
</div> |
|
|
<div id="footer"> |
|
|
<div id="footer-text"> |
|
|
Last updated 2023-04-19 05:40:20 UTC |
|
|
</div> |
|
|
</div> |
|
|
</body> |
|
|
</html> |
