Regressioner är ett stort problem inom mjukvaruindustrin. Men det är svårt att lägga några riktiga siffror bakom det påståendet.

Det finns några siffror om programfel i allmänhet, som en NIST-studie från 2002 [1] som sa:

Och sedan:

Slutligen började slutsatsen med:

Det finns andra uppskattningar som säger att 80 % av kostnaden relaterad till programvara går till underhåll [2].

Men, enligt Wikipedia [3]:

Men vi kan gissa att det är mycket kostsamt att förbättra befintlig programvara eftersom man måste se upp för regressioner. Åtminstone skulle detta göra ovanstående studier konsekventa sinsemellan.

Naturligtvis utvecklas någon form av programvara, används sedan under en tid utan att förbättras särskilt mycket, och kastas sedan slutligen bort. I det här fallet kanske regressioner naturligtvis inte är ett stort problem. Men å andra sidan finns det mycket stor programvara som kontinuerligt utvecklas och underhålls under åratal eller till och med tiotals år av många människor. Och eftersom det ofta finns många människor som är beroende (ibland kritiskt) av sådan programvara, är regressioner ett riktigt stort problem.

En sådan programvara är Linuxkärnan. Och om vi tittar på Linuxkärnan kan vi se att mycket tid och ansträngning läggs ner på att bekämpa regressioner. Utgivningscykeln börjar med ett två veckor långt sammanslagningsfönster. Sedan taggas den första releasekandidatversionen (rc). Och därefter kommer cirka sju eller åtta rc-versioner att dyka upp med ungefär en veckas mellanrum, innan den slutliga utgåvan.

Tiden mellan den första rc-utgåvan och den slutliga utgåvan är tänkt att användas för att testa rc-versioner och bekämpa programfel och särskilt regressioner. Och denna tid är mer än 80 % av utgivningscykeltiden. Men detta är inte slutet på kampen än, eftersom den naturligtvis fortsätter efter utgivningen.

Och så här säger Ingo Molnar (en välkänd Linuxkärnutvecklare) om sin användning av git bisect:

Så utvecklare bekämpar regressioner hela tiden, och det är faktiskt välkänt att programfel bör åtgärdas så snart som möjligt, så snart de hittas. Det är därför det är intressant att ha bra verktyg för detta ändamål.

Vilka verktyg används då för att bekämpa regressioner? De är nästan desamma som används mot vanliga programfel. De enda specifika verktygen är testsviter och verktyg som "git bisect".

Testsviter är väldigt bra. Men när de används ensamma är det meningen att de ska användas så att alla tester kontrolleras efter varje incheckning. Det betyder att de inte är särskilt effektiva, eftersom många tester körs utan intressanta resultat, och de lider av kombinatorisk explosion.

Problemet är faktiskt att stor programvara ofta har många olika konfigurationsalternativ och att varje testfall ska godkännas för varje konfiguration efter varje incheckning. Så om du för varje utgåva har: N konfigurationer, M incheckningar och T testfall, bör du utföra:

där N, M och T alla växer med storleken på din programvara.

Så snart kommer det inte att vara möjligt att testa allt helt.

Om några programfel slinker igenom testsviten kan du lägga till ett nytt test. Men om du vill använda den förbättrade testsviten för att hitta var programfelet smög sig in måste du antingen emulera en binärsökningsprocess eller helt enkelt testa varje incheckning bakåt från den "dåliga" incheckning du har, vilket kan vara mycket slösaktigt.

Det första git bisect-underkommandot att använda är git bisect start för att starta sökningen. Därefter måste gränser sättas för att begränsa incheckningsutrymmet. Detta görs vanligtvis genom att ange en "dålig" och minst en "bra" incheckning. De kan skickas i det första anropet till git bisect start så här:

eller så kan de ställas in med hjälp av:

och:

där DÅLIG, BRA och INCHECKNING är namn som kan lösas till en incheckning.

Sedan kommer "git bisect" att checka ut en incheckning som den väljer och be användaren att testa den, så här:

Observera att exemplet vi kommer att använda egentligen är ett leksaksexempel. Vi kommer att leta efter den första incheckningen som har en version som "2.6.26-något", det vill säga den incheckning som har en "SUBLEVEL = 26"-rad i Makefile-filen på översta nivån. Detta är ett leksaksexempel eftersom det finns bättre sätt att hitta denna incheckning med Git än att använda "git bisect" (till exempel "git blame" eller "git log -S<string>").

Vid det här laget finns det i princip två sätt att köra sökningen. Den kan köras manuellt av användaren eller så kan den köras automatiskt av ett skript eller ett kommando.

Om användaren kör den, måste användaren i varje steg av sökningen testa den aktuella incheckningen och avgöra om den är "bra" eller "dålig" med hjälp av kommandona "git bisect good" respektive "git bisect bad" som har beskrivits ovan. Till exempel:

Efter ytterligare några sådana steg hittar git bisect till slut en första dålig incheckning:

Vid det här laget kan vi se vad incheckningen gör, kolla in den (om den inte redan är utcheckad) eller experimentera med den, till exempel:

Och när vi är klara kan vi använda "git bisect reset" för att gå tillbaka till grenen vi var i innan vi började binärsökningen:

Det andra sättet att driva bisektionsprocessen är att be "git bisect" att starta ett skript eller kommando vid varje bisektionssteg för att veta om den aktuella incheckningen är "bra" eller "dålig". För att göra det använder vi kommandot "git bisect run". Till exempel:

I det här exemplet skickade vi grep ^SUBLEVEL = 25' Makefile som parameter till git bisect run. Det betyder att grep-kommandot körs vid varje steg. Om det avslutas med kod 0 (lyckat) markerar git bisect det aktuella tillståndet som "bra". Om det avslutas med kod 1 (eller någon kod mellan 1 och 127, utom specialkoden 125) markeras det aktuella tillståndet som "dåligt".

Avslutningskoder mellan 128 och 255 är särskilda för "git bisect run". De gör att bisektionsprocessen stoppas omedelbart. Detta är till exempel användbart om det körda kommandot tar för lång tid, eftersom du då kan avbryta det med en signal och därmed stoppa bisektionen.

Det kan också vara användbart att i skript som körs via "git bisect run" göra "exit 255" om en mycket onormal situation upptäcks.

Ibland händer det att det aktuella tillståndet inte kan testas, till exempel om det inte kompileras på grund av att det fanns ett programfel som förhindrade det vid den tidpunkten. Det är detta den speciella avslutningskoden 125 är till för. Den talar om för "git bisect run" att den aktuella incheckningen ska markeras som otestbar och att en annan ska väljas och checkas ut.

Om binärsökningsprocessen körs manuellt kan du använda "git bisect skip" för att göra samma sak. (Faktum är att den speciella avslutningskoden 125 gör att "git bisect run" använder "git bisect skip" i bakgrunden.)

Eller om du vill ha mer kontroll kan du inspektera det aktuella tillståndet med hjälp av till exempel "git bisect visualize". Det kommer att starta gitk (eller "git log" om miljövariabeln DISPLAY inte är satt) för att hjälpa dig hitta en bättre binärsökningspunkt.

Hur som helst, om du har en rad otestbara incheckningar, kan det hända att regressionen du letar efter har introducerats av en av dessa otestbara incheckningar. I det här fallet är det inte möjligt att säga säkert vilken incheckning som introducerade regressionen.

Om du använder "git bisect skip" (eller om run-skriptet avslutas med specialkod 125) kan du få ett resultat som detta:

Om du vill visa andra din binärsökningsprocess kan du hämta en logg med hjälp av till exempel:

Och det är möjligt att spela upp det med hjälp av:

Eftersom Git-incheckningar bildar en riktad acyklisk graf (DAG) är det inte helt enkelt att hitta den bästa bisektionsincheckningen att testa i varje steg. Linus hittade och implementerade dock en "verkligt dum" algoritm, senare förbättrad av Junio Hamano, som fungerar ganska bra.

Algoritmen som "git bisect" använder för att hitta den bästa bisektionsincheckningen när inga incheckningar har hoppats över är följande:

1) behåll endast de incheckningar som:

a) är förfäder till den "dåliga" incheckningen (inklusive den "dåliga" incheckningen själv), b) inte är förfäder till en "bra" incheckning (exklusive de "bra" incheckningarna).

Det innebär att vi blir av med de ointressanta incheckningarna i DAG:en.

Om vi till exempel börjar med en graf som denna:

där B är den "dåliga" incheckningen, "G" är "bra" incheckningar och W, X och Y är andra incheckningar, får vi följande graf efter detta första steg:

Så endast W- och B-incheckningar kommer att behållas. Eftersom incheckningar X och Y kommer att ha tagits bort av regel a) respektive b), och eftersom incheckningar G också tas bort av regel b).

Observera för Git-användare att det är likvärdigt med att endast behålla incheckningen som ges av:

Observera också att vi inte kräver att de incheckningar som sparas ska vara efterkommande av en "bra" incheckning. Så i följande exempel kommer incheckningar W och Z att sparas:

2) börja från grafens "bra" ändar och associera till varje incheckning antalet förfäder den har plus ett

Till exempel med följande graf där H är den "dåliga" incheckningen och A och D är några föräldrar till några "bra" incheckningar:

detta kommer att ge:

3) associera till varje incheckning: min(X, N - X)

där X är värdet som är associerat med incheckningen i steg 2) och N är det totala antalet incheckningar i grafen.

I exemplet ovan har vi N = 8, så detta ger:

4) Den bästa binärsökningspunkten är den incheckning med det högsta associerade numret

I exemplet ovan är alltså den bästa bisektionspunkten incheckning C.

5) observera att vissa genvägar är implementerade för att snabba upp algoritmen

Eftersom vi vet N från början, vet vi att min(X, N - X) inte kan vara större än N/2. Så om vi under steg 2) och 3) skulle associera N/2 till en incheckning, då vet vi att detta är den bästa binärsökningspunkten. Så i det här fallet kan vi helt enkelt sluta bearbeta alla andra incheckningar och returnera den aktuella incheckningen.

För alla incheckningsgrafer kan du se numret som är associerat med varje incheckning med hjälp av "git rev-list --bisect-all".

Till exempel för grafen ovan, ett kommando som:

skulle mata ut något liknande:

Låt oss först definiera "bästa bisektionspunkt". Vi säger att en incheckning X är en bästa bisektionspunkt, eller bästa bisektionsincheckning, om kunskap om dess tillstånd ("bra" eller "dåligt") ger så mycket information som möjligt, oavsett om tillståndet råkar vara "bra" eller "dåligt".

Det betyder att de bästa bisektionsincheckningarna är de där följande funktion är maximal:

där information_if_good(X) är informationen vi får om X är bra och information_if_bad(X) är informationen vi får om X är dåligt.

Nu antar vi att det bara finns en "första dåliga incheckning". Det betyder att alla dess efterföljare är "dåliga" och alla andra incheckningar är "bra". Vi antar också att alla incheckningar har lika stor sannolikhet att vara bra, dåliga eller den första dåliga incheckningen, så att kunskap om tillståndet för c incheckningar alltid ger samma mängd information oavsett var de ligger i grafen och oavsett värdet på c. (Det vill säga: att de till exempel ligger på en viss gren eller nära en bra eller dålig incheckning antas inte ge mer eller mindre information.)

Låt oss också anta att vi har en rensad graf som efter steg 1) i bisektionsalgoritmen ovan. Det betyder att vi kan mäta informationen vi får i termer av antalet incheckningar vi kan ta bort från grafen.

Och låt oss ta en incheckning X i grafen.

Om X visar sig vara "bra", då vet vi att dess förfäder alla är "bra", så vi vill säga att:

Detta är sant eftersom vi i steg 1) b) tar bort förfäderna till de "bra" incheckningarna.

Om X visar sig vara "dålig" vet vi att dess efterföljare alla är "dåliga", så vi vill säga att:

Men detta är fel eftersom vi i steg 1) a) bara behåller förfäderna till den dåliga incheckningen. Så vi får mer information när en incheckning markeras som "dålig", eftersom vi också vet att förfäderna till den tidigare "dåliga" incheckningen som inte är förfäder till den nya "dåliga" incheckningen inte är den första dåliga incheckningen. Vi vet inte om de är bra eller dåliga, men vi vet att de inte är den första dåliga incheckningen eftersom de inte är förfäder till den nya "dåliga" incheckningen.

Så när en incheckning markeras som "dålig" vet vi att vi kan ta bort alla incheckningar i grafen förutom de som är föregångare till den nya "dåliga" incheckningen. Det betyder att:

där N är antalet incheckningar i den (rensade) grafen.

I slutändan betyder detta att vi, för att hitta de bästa bisektionsincheckningarna, bör maximera funktionen:

And this is nice because at step 2) we compute number_of_ancestors(X) and so at step 3) we compute f(X).

Låt oss ta följande graf som exempel:

Om vi beräknar följande icke-optimala funktion på den:

får vi:

men med algoritmen som används av git bisect får vi:

Så vi valde G, H, K eller L som den bästa binärsökningspunkten, vilket är bättre än F. För om till exempel L är dålig, då vet vi inte bara att L, M och N är dåliga utan också att G, H, I och J inte är den första dåliga incheckningen (eftersom vi antar att det bara finns en första dålig incheckning och den måste vara en förfader till L).

Så den nuvarande algoritmen verkar vara den bästa möjliga med tanke på vad vi från början antog.

När vissa incheckningar har hoppats över (med "git bisect skip") är bisektionsalgoritmen densamma för steg 1) till 3). Därefter används ungefär följande steg:

6) sortera incheckningarna efter fallande associerat värde

7) om den första incheckningen inte har hoppats över kan vi returnera den och stanna här

8) annars filtrera bort alla överhoppade incheckningar i den sorterade listan

9) använd en pseudoslumptalsgenerator (PRNG) för att generera ett slumptal mellan 0 och 1

10) multiplicera slumptalet med dess kvadratrot för att vinkla det mot 0

11) multiplicera resultatet med antalet incheckningar i den filtrerade listan för att få ett index i listan

12) returnera incheckningen vid det beräknade indexet

Efter steg 7) (i skip-algoritmen) skulle vi kunna kontrollera om den andra incheckningen hade hoppats över och returnera den om så inte var fallet. Det var faktiskt den algoritm vi använde från att "git bisect skip" utvecklades i Git 1.5.4 (släppt 1 februari 2008) fram till Git 1.6.4 (släppt 29 juli 2009).

Men Ingo Molnar och H. Peter Anvin (en annan välkänd Linuxkärnutvecklare) klagade båda på att ibland råkade de bästa binärsökningspunkterna vara i ett område där alla incheckningar är otestbara. Och i det här fallet ombads användaren att testa många otestbara incheckningar, vilket kunde vara mycket ineffektivt.

Faktum är att otestbara incheckningar ofta är otestbara eftersom ett fel introducerades vid en tidpunkt, och det felet åtgärdades först efter att många andra incheckningar introducerades.

Det här fel är naturligtvis oftast inte relaterat till det fel vi försöker hitta i incheckningsgrafen. Men det hindrar oss från att veta om det intressanta "dåliga beteendet" finns eller inte.

Det är alltså ett faktum att incheckningar nära en otestbar incheckning har hög sannolikhet att själva vara otestbara. Och de bästa bisektionsincheckningarna hittas ofta i kluster (på grund av bisektionsalgoritmen).

Det är därför en dålig idé att bara välja den näst bästa icke-överhoppade bisektionsincheckningen när den första har hoppats över.

Vi fann att de flesta incheckningar i grafen kan ge en hel del information när de testas. Och de incheckningar som i genomsnitt inte ger mycket information är de som ligger nära de bra och dåliga incheckningar.

Så att använda en PRNG med en bias för att gynna incheckningar bort från de bra och dåliga incheckningar verkade vara ett bra val.

En uppenbar förbättring av algoritmen vore att leta efter en incheckning med ett associerat värde nära den bästa bisektionsincheckningen, men på en annan gren, innan PRNG används. Om en sådan incheckning finns är det mindre sannolikt att den också är otestbar, och den ger därför troligen mer information än en nästan slumpmässigt vald incheckning.

Det finns ytterligare en justering i binärsökningsalgoritmen som inte har beskrivits i "binärsökningsalgoritmen" ovan.

I de tidigare exemplen antog vi att de "bra" incheckningarna var förfäder till den "dåliga" incheckningen. Men detta är inget krav för "git bisect".

Naturligtvis kan den "dåliga" incheckningen inte vara en förfader till en "bra" incheckning, eftersom förfäderna till bra incheckningar antas vara "bra". Och alla "bra" incheckningar måste vara relaterade till den dåliga incheckningen. De kan inte ligga på en gren som saknar koppling till grenen med den "dåliga" incheckningen. Men det är möjligt att en bra incheckning är relaterad till en dålig incheckning utan att vara vare sig förfader eller efterföljare till den.

Till exempel kan det finnas en "main"-gren och en "dev"-gren som avgrenades från huvudgrenen vid en incheckning med namnet "D" så här:

Incheckningen "D" kallas en "sammanslagningsbas" för grenarna "main" och "dev" eftersom det är den bästa gemensamma förfadern för dessa grenar för en sammanslagning.

Låt oss nu anta att incheckning J är dålig och incheckning G är bra, och att vi tillämpar bisektionsalgoritmen som den tidigare beskrivits.

Som beskrivs i steg 1) b) i bisektionsalgoritmen tar vi bort alla förfäder till de bra incheckningarna eftersom de också ska vara bra.

Så skulle vi bara ha kvar:

Men vad händer om den första dåliga incheckningen är "B", och den har åtgärdats i huvudgrenen av incheckning "F"?

Resultatet av en sådan bisektion skulle bli att vi hittar H som första dåliga incheckning, när det i själva verket är B. Det vore alltså fel!

Och ja, det kan hända i praktiken att personer som arbetar på en gren inte är medvetna om att personer som arbetar på en annan gren har fixat ett programfel! Det kan också hända att F har fixat mer än ett programfel eller att det är en återställning av någon stor utvecklingssatsning som inte var redo att släppas.

Utvecklingsteam underhåller ofta både en utvecklingsgren och en underhållsgren, och det vore väldigt praktiskt om "git bisect" bara fungerade när de vill bisektera en regression på utvecklingsgrenen som inte finns på underhållsgrenen. De borde kunna starta bisektering med:

För att möjliggöra den extra funktionen gör vi följande när en bisektion startas och vissa bra incheckningar inte är förfäder till den dåliga incheckningen: först beräknas sammanslagningsbaserna mellan den dåliga och de bra incheckningarna, och dessa sammanslagningsbaser väljs som de första incheckningarna att checka ut och testa.

Om det visar sig att en sammanslagningsbas är dålig stoppas bisektionsprocessen med ett meddelande som:

där BBBBBB är sha1-hashen för den felaktiga merge-basen och [GGGGGG,…​] är en kommaseparerad lista över sha1 för de bra incheckningar.

Om någon av sammanslagningsbaserna hoppas över fortsätter bisektionsprocessen, men följande meddelande skrivs ut för varje överhoppad sammanslagningsbas:

där BBBBBB är sha1-hashen för den dåliga incheckningen, MMMMMM är sha1-hashen för den sammanslagningsbas som hoppas över och [GGGGGG,…​] är en kommaseparerad lista över sha1 för de bra incheckningen.

Om det inte finns någon dålig sammanslagningsbas fortsätter bisektionsprocessen som vanligt efter detta steg.

Om du både har en testsvit och använder git bisect blir det mindre viktigt att kontrollera att alla tester passerar efter varje incheckning. Det är ändå en god idé att ha vissa kontroller för att undvika att för mycket går sönder, eftersom det annars kan göra det svårare att bisektera andra programfel.

Du kan fokusera dina ansträngningar på att kontrollera vid några få punkter (till exempel rc- och betaversioner) att alla T-testfall klarar alla N-konfigurationer. Och när vissa tester inte klarar kan du använda "git bisect" (eller hellre "git bisect run"). Så du bör utföra ungefär:

där c är antalet testrundor (alltså en liten konstant) och b är förhållandet mellan programfel per incheckning (förhoppningsvis också en liten konstant).

Så det är förstås mycket bättre eftersom det är O(N * T) kontra O(N * T * M) om du testar allt efter varje incheckning.

Det betyder att testsviter är bra för att förhindra att vissa programfel checkas in, och de är också bra på att visa att programfel finns. Men de är inte lika bra på att visa var programfelen introducerades. För att få fram det effektivt behövs git bisect.

Det andra fina med testsviter är att när du har en vet du redan hur man testar för dåligt beteende. Den kunskapen kan du använda för att skapa ett nytt testfall för "git bisect" när en regression verkar ha uppstått. Då blir det lättare att bisektera programfelet och åtgärda den, och därefter kan du lägga till det nya testfallet i testsviten.

Om du vet hur man skapar testfall och hur man bisekterar hamnar du i en positiv spiral:

fler tester ⇒ lättare att skapa tester ⇒ lättare att binärsöka ⇒ fler tester

Så testsviter och "git bisect" är kompletterande verktyg som är mycket kraftfulla och effektiva när de används tillsammans.

Du kan mycket enkelt automatiskt binärsöka trasiga byggen med hjälp av något i stil med:

Till exempel:

Å andra sidan, om du gör detta ofta, kan det vara värt att ha skript för att undvika för mycket skrivande.

Här är ett exempelskript som är något modifierat från ett verkligt skript som används av Junio Hamano [4].

Det här skriptet kan skickas till "git bisect run" för att hitta den incheckning som introducerade en prestandaregression:

Det är uppenbarligen en bra idé att inte ha incheckningar med ändringar som medvetet förstör saker, även om andra incheckningar senare åtgärdar felet.

Det är också en bra idé när man använder VCS att bara ha en liten logisk ändring i varje incheckning.

Ju mindre ändringarna är i din incheckning, desto effektivast blir "git bisect". Och du kommer förmodligen att behöva "git bisect" mindre från början, eftersom små ändringar är lättare att granska även om de bara granskas av incheckaren.

En annan bra idé är att ha bra incheckningsmeddelanden. De kan vara till stor hjälp för att förstå varför vissa ändringar har gjorts.

Dessa allmänna bästa praxis är mycket användbara om du bisekterar ofta.

Sammanslagningar kan i sig introducera regressioner även när sammanslagningen inte kräver konfliktlösning i källkoden. Det beror på att en semantisk förändring kan ske i en gren utan att den andra grenen känner till den.

Till exempel kan en gren ändra semantiken för en funktion medan den andra grenen lägger till fler anrop till samma funktion.

Det här förvärras kraftigt om många filer måste justeras för att lösa konflikter. Därför kallas sådana sammanslagningar "onda sammanslagningar". De kan göra regressioner mycket svåra att spåra. Det kan till och med vara missvisande att veta vilken den första dåliga incheckningen är om den råkar vara en sådan sammanslagning, eftersom man då lätt tror att felet kommer från dålig konfliktlösning när det i själva verket kommer från en semantisk förändring i en gren.

Hur som helst kan "git rebase" användas för att linjärisera historiken. Det kan antingen användas för att undvika sammanslagning från början, eller för att bisektera i en linjär historik i stället för en icke-linjär, vilket bör ge mer information vid en semantisk förändring i en gren.

Sammanslagningar kan också förenklas genom att använda mindre grenar eller genom att använda många ämnesgrenar i stället för bara långa versionsrelaterade grenar.

Testning kan också göras oftare i särskilda integrationsgrenar, som linux-next för Linuxkärnan.

Ett särskilt arbetsflöde för att bearbeta regressioner kan ge utmärkta resultat.

Här är ett exempel på ett arbetsflöde som används av Andreas Ericsson:

Och här är vad Andreas sa om detta arbetsflöde [5]:

Det är uppenbart att detta arbetsflöde använder den positiva spiralen mellan testsviter och "git bisect". Det gör den till ett standardförfarande för att hantera regressioner.

I andra meddelanden säger Andreas att de också använder de "bästa praxis" som beskrivs ovan: små logiska incheckningar, ämnesgrenar, ingen ondska-sammanslagning,…​ Dessa metoder förbättrar alla incheckning-grafens binärsökningsbarhet genom att göra det enklare och mer användbart att dela upp det.

Ett bra arbetsflöde bör alltså utformas kring punkterna ovan. Det gör bisektering enklare, mer användbar och mer standardiserad.

En fördel med "git bisect" är att det inte bara är ett utvecklarverktyg. Det kan användas effektivt av QA-personal eller till och med slutanvändare (om de har tillgång till källkoden eller kan få tillgång till alla byggen).

Vid ett tillfälle diskuterades på Linuxkärnans e-postlista om det var okej att alltid be slutanvändare bisektera, och starka argument lades fram för att detta är rimligt.

Till exempel skrev David Miller [6]:

Det betyder att det ofta är "billigare" om QA-personal eller slutanvändare kan göra det.

Det intressanta är också att slutanvändare som rapporterar programfel (eller QA-personal som reproducerat ett programfel) har tillgång till miljön där programfelet uppstår. Därför kan de ofta lättare reproducera en regression. Om de dessutom kan bisektera går det att få ut mer information ur miljön där programfelet uppstår, vilket gör det enklare att förstå och därefter åtgärda programfelet.

För öppen källkodsprojekt kan detta vara ett bra sätt att få mer användbara bidrag från slutanvändare och introducera dem till QA- och utvecklingsarbete.

I vissa fall, som vid kärnutveckling, kan det vara värt att utveckla mer komplexa skript för att kunna automatisera bisektering fullt ut.

Här är vad Ingo Molnar säger om det [7]:

Vi har sett att testsviter och git bisect är mycket kraftfulla när de används tillsammans. De kan bli ännu kraftfullare om man kan kombinera dem med andra system.

Till exempel skulle vissa testsviter kunna köras automatiskt på natten med ovanliga (eller till och med slumpmässiga) konfigurationer. Och om en regression hittas av en testsvit, kan "git bisect" startas automatiskt, och dess resultat kan skickas via e-post till författaren till den första felaktiga incheckning som hittas av "git bisect", och kanske även till andra personer. Och en ny post i felrapporteringssystemet skulle också kunna skapas automatiskt.

Vi såg tidigare att "git bisect skip" nu använder en PRNG för att försöka undvika områden i incheckning-grafen där commits är otestbara. Problemet är att ibland kommer den första felaktiga incheckning att vara i ett otestbart område.

För att förenkla diskussionen antar vi att det otestbara området är en enkel kedja av incheckningar och att det skapades av ett brott som introducerades av en incheckning (låt oss kalla den BBC, bisect breaking commit) och senare rättades av en annan (låt oss kalla den BFC, bisect fixing commit).

Till exempel:

där vi vet att Y är bra och BFC är dålig, och där BBC samt X1 till X6 är otestbara.

I det här fallet, om du bisekterar manuellt, kan du skapa en särskild gren som börjar precis före BBC. Den första incheckningen i den grenen bör vara BBC med BFC sammanpressad in i den. De övriga incheckningarna i grenen bör vara incheckningarna mellan BBC och BFC ombaserade på grenens första incheckning, samt incheckningen efter BFC också ombaserad.

Till exempel:

där incheckningar citerade med ' har ombaserats.

Du kan enkelt skapa en sådan gren med Git med hjälp av interaktiv ombasering.

Till exempel med hjälp av:

och därefter flytta BFC efter BBC och pressa samman den.

Efter det kan du börja bisektera som vanligt i den nya grenen, och du bör till slut hitta den första dåliga incheckningen.

Till exempel:

Om du använder "git bisect run" kan du använda samma manuella fix som ovan och sedan starta en annan "git bisect run" i den speciella grenen. Eller som "git bisect" manualsidan säger, kan skriptet som skickas till "git bisect run" applicera en patch innan det kompilerar och testar programvaran [8]. Patchen bör omvandla en aktuell otestbar incheckning till en testbar. Så testningen kommer att resultera i "bra" eller "dålig" och "git bisect" kommer att kunna hitta den första dåliga incheckningen. Och skriptet bör inte glömma att ta bort patchen när testningen är klar innan det avslutar skriptet.

(Observera att du i stället för en patch kan använda "git cherry-pick BFC" för att applicera fixen, och i det fallet bör du använda "git reset --hard HEAD^" för att återställa cherry-pick efter testningen och innan skriptet avslutas.)

Men ovanstående sätt att hantera otestbara områden är lite klumpiga. Särskilda grenar är bra eftersom de kan delas mellan utvecklare som vanliga grenar, men risken är att det blir många sådana grenar. Dessutom stör det det normala arbetsflödet i "git bisect". Om du vill köra "git bisect run" helt automatiskt måste du därför lägga till särskild kod i skriptet för att starta om bisekteringen i de särskilda grenarna.

Hur som helst kan man i exemplet med den särskilda grenen ovan se att incheckningarna Z' och Z bör peka på samma källkodstillstånd (samma "träd" i Git-språk). Det beror på att Z' uppstår av att applicera samma ändringar som Z, men i lite annan ordning.

Om vi alltså bara kunde "ersätta" Z med Z' när vi bisekterar, skulle vi inte behöva lägga till något i skriptet. Det skulle bara fungera för alla i projektet som delar de särskilda grenarna och ersättningarna.

Med exemplet ovan skulle det ge:

Det är därför kommandot "git replace" skapades. Tekniskt sett lagrar det ersättningsreferenser i hierarkin "refs/replace/". Dessa referenser är som grenar (lagrade i "refs/heads/") eller taggar (lagrade i "refs/tags/"), vilket innebär att de kan delas automatiskt mellan utvecklare på samma sätt som grenar och taggar.

"git replace" är en mycket kraftfull mekanism. Den kan användas för att rätta incheckningar i redan publicerad historik, till exempel för att ändra incheckningsmeddelandet eller författaren. Den kan också användas i stället för git "grafts" för att länka ett kodförråd till ett annat äldre kodförråd.

Det är faktiskt den sista funktionen som "sålde in" den till Git-gemenskapen, så den finns nu i "master"-grenen i Gits eget kodförråd och skulle släppas i Git 1.6.5 i oktober eller november 2009.

Ett problem med "git replace" är att det för närvarande lagrar alla ersättningsreferenser i "refs/replace/", men det vore kanske bättre om ersättningsreferenser som bara är användbara för bisektering låg i "refs/replace/bisect/". På så sätt skulle dessa ersättningsreferenser kunna användas enbart för bisektering, medan andra referenser direkt i "refs/replace/" skulle användas nästan hela tiden.

En annan möjlig förbättring av "git bisect" skulle vara att valfritt lägga till redundans i de utförda testerna så att det skulle vara mer tillförlitligt vid spårning av sporadiska programfel.

Det här har begärts av vissa kärnutvecklare eftersom vissa programfel, så kallade sporadiska programfel, inte förekommer i alla kärnversioner eftersom de är mycket beroende av kompilatorns utdata.

Tanken är att till exempel vart tredje test kan "git bisect" be användaren testa en incheckning som redan bedömts som "bra" eller "dålig" (eftersom en av dess efterföljare respektive förfäder redan bedömts så). Om en incheckning tidigare råkat klassificeras fel kan bisekteringen då avbrytas tidigt, förhoppningsvis innan för många misstag hunnit göras. Därefter måste användaren undersöka vad som hände och starta om bisekteringen med en korrigerad bisektionslogg.

Det finns redan ett projekt som heter BBChop skapat av Ealdwulf Wuffinga på Github som gör något liknande med hjälp av Bayesiansk sökteori [9]:

Men BBChop är oberoende av alla VCS och det skulle vara enklare för Git-användare att ha något integrerat i Git.