> > 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.
