vcs:why

[Xin]

Es ist immerhin die Info da, wo man die Information bekommt, von daher passt das schon.
Grundsätzlich ist ein RTFM nicht der gewünschte Stil hier.
Was bisect nun macht, weiß ich nun auch nicht, auch nicht, ob sich ein Wechsel auf GIT nun lohnt, weil ich nun eine Ahnung habe, was bisect ist, für die es sich lohnt, die Dokumentation dann zu lesen.
Die Antwort würde ich also als okay bezeichnen, aber noch nicht als inspirierend. Hat also noch etwas Potential in meinem Verständnis

[mfro]

Die Antwort würde ich also als okay bezeichnen, aber noch nicht als inspirierend. Hat also noch etwas Potential in meinem Verständnis

Sorry, aber ich war tatsächlich der Ansicht, daß es sich um "Programmierer-Allgemeinwissen" handelt.

Jeder, der an einem komplexen Softwareprojekt gearbeitet hat, hatte sicher schon das Problem: ein Teil, den man als "abgehangen" und "rock solid" betrachtet (und deswegen natürlich seit Monaten weder angeschaut nocht getestet) hat, funktioniert kurz vor dem Release nicht mehr - irgendein unbeabsichtigter Seiteneffekt hat sich irgendwo eingeschlichen und den "golden code" verhunzt. Was das war, weiß man nicht, bloß daß es beim letzten Release noch einwandfrei funktioniert hat.

Super-GAU. 800 commits seit dem letzten Release und einer davon hat einen Fehler ...
Jetzt geht die Sucherei los.

Und die kann einem "git bisect" (weitgehend) abnehmen.

Code: Alles auswählen

git bisect start                   
git bisect bad                           # aktuelle Version ist kaputt
git bisect good v3_0                 # bei dem tag hat es noch getan

git checkt (per binärer Suche) nun commits zwischen "good" und "bad" aus, man compiliert und testet. Und erklärt git dann, ob die ausgecheckte Version entweder "good" oder "bad", der Fehler also noch nicht oder schon drin ist.

Code: Alles auswählen

git bisect good           # noch gut, der Fehler muß sich in einem späteren commit eingeschlichen haben

Code: Alles auswählen

git bisect bad             # Version ist bereits "kaputt", Fehler muß davor liegen

Entsprechend checkt git dann (per binärer Suche, also mit der minimal notwendigen Anzahl an Schritten) aus dem Bereich zwischen "good" und "bad" aus, man testet erneut und meldet git wieder entweder "good" oder "bad" zurück.
Das macht man solange, bis git irgendwann meldet:

Code: Alles auswählen

f195c891a9d8aee31e161fe31662a26d8961xxxx is the first bad commit
commit f195c891a9d8aee31e161fe31662a26d896189f1
Author: xxxx <mfro@mxxf.de>
Date:   Tue May 9 13:48:37 2017 +0200
...

Wenn der commit jetzt noch einigermaßen übersichtlich ist, hat man den Fehler in ein paar Minuten gefunden, für den man sonst möglicherweise Stunden gebraucht hätte. Natürlich könnte man dasselbe auch "zu Fuß" machen, aber ich zumindest habe mich da regelmäßig "verheddert".