On Sat, Apr 22, 2017 at 3:37 PM, Johannes Sixt <j6t@xxxxxxxx> wrote: > Am 21.04.2017 um 14:29 schrieb Christian Couder: >> >> First bisect should ask you to test merge bases only if there are >> "good" commits that are not ancestors of the "bad" commit. > > > That's a tangent, but I have never understood why this needs to be so. > Consider this: > > o--o--o--o--o--o--o--o--B > / / > -o--o--o--o--g--o--o--o--o--G > > When I mark B as bad and G as good, why would g have to be tested first? It is because g could be bad if the bug has been fixed between g and G. If this happens and we don't test g, we would give a wrong result. > This is exactly what I do when I bisect in Git history: I mark the latest > commits on git-gui and gitk sub-histories as good, because I know they can't > possibly be bad. (In my setup, these two histories are ahead of pu and > next.) Yeah, it is safe to do that in this case as we test the merge bases.