> > 1. there may be feature branches that bypass the known good starting > > commit, which can cause understanding issues as those side > > branches that predate the start point are also considered > > potential bu commits. > > ok, but let's make sure i understand what defines a possible commit > that "introduces" the bug. if i define two bisection commits <good> > and <bad>, then i've always assumed that what i'm after is a commit > <X> for which: > > 1) <X> is reachable from <bad> > 2) <good> is reachable from <X> > > this seems fairly obvious.
Well, maybe _you_ are after such a commit, but bisect is after a commit <X> for which 1) <X> is reachable from <bad> (i.e. the same as your first point) 2) <X> is not reachable from <good> (which is not the same as your second point, notably when it comes to commits on side branches that branched off before <good> and got merged later). > now, as you suggest, it's possible that the > "bug" was introduced on a feature branch that bypasses my choice of > <good> but, at *some* point, that feature branch would have to be > merged to the point where it was now reachable from <bad> and, in the > context of bisection, *that* merge commit would represent where the > bug was introduced, no? No. Consider this piece of history: <good> <bad> v v --a---b---C---d---e---M---k---L-- \ / f---g---H---i---j ^ first bad Then the command 'git bisect start L C' will first consider the following as "possible commit that introduces the bug": d e f g H i j M k L (IOW all commits listed by 'git log ^C L') and will then systematically narrow down until it will find commit H as the transition from good to bad.